Re: ENOSPC while creating snapshot

["Martin Mlynář" <nexus@smoula.net>]

On 5.3.2016 06:34, Duncan wrote:
> Chris Murphy posted on Fri, 04 Mar 2016 19:46:34 -0700 as excerpted:
>
>> On Fri, Mar 4, 2016 at 4:16 PM, Martin Mlynář <nexus@smoula.net> wrote:
>
> [Mount options line split/wrapped for followup]
>
>>>>> rw,noatime,nodatasum,nodatacow,ssd,discard,space_cache,
>>>>> enospc_debug,commit=900,subvolid=5,subvol=/
>>>>
>>>> Most likely unrelated but commit time of 15 minutes? Umm, OK why?
>>>
>>> I'm trying to reduce writes to my ssd.
>>
>> This will not reduce writes. It will only delay them. And it increases
>> the chance of data loss by a lot.
>
> AFAIK, to the extent that temporary files are created and then deleted
> again, within that 900 seconds aka 15 minutes, it will indeed reduce
> writes.
>
> This can be the case for the build-tmp location for people running build-
> from-sources distros such as gentoo, for instance, as many packages will
> be built and tmp-installed to that build-tmp, before being quick-merged
> to the live system and the work deleted from build-tmp in well under 15
> minutes, at least on today's reasonably powerful quad-core-plus systems.
> Tho on gentoo, the recommendation for those with the memory available is
> to point that build-tmp at a tmpfs instead of a permanent-storage backed
> filesystem of any sort.
>
> And in general, for those without the memory to support build-tmp in
> tmpfs, a 15-minute commit time isn't going to help either, because if
> they have enough memory to avoid flushing to free up memory for that full
> 15 minutes, they obviously have enough memory to store all those files
> that would be in tmpfs if they'd have simply pointed build-tmp at that,
> instead.
>
> Another use-case is laptops and other mobile systems with enough memory
> to cache the normal working set, is to power down the storage devices for
> as long as possible between powerups.  However, the heavy power usage
> there is normally on spinning up the disk and/or keeping it spinning, and
> SSDs obviously aren't subject to that.  While some small amount of power
> may still be saved by powering down the SSD, I expect it to be pretty
> small, and the writes are going to take the same amount of power no
> matter when they're done.
>
> In either case, 15 minute commit times are rather extreme, because as has
> been pointed out, that's potentially 15 minutes of lost work should the
> system crash before those writes are completed, and losing 15 minutes
> worth of work is well beyond the acceptable risk level for most people.
> 5 minutes, much more common, 10 minutes, not so common but you'll fine
> people doing it.  15 minutes, pretty rare, I expect.
>
> The point being, yes, there are use-cases where 15 minute commit times
> makes sense.  But the given reason, a bare wish to reduce writes to the
> ssd, without support such as one of the above use-cases or something
> similar, really doesn't make sense, at least on its face.  I'll agree
> with other posters on that.
Thank you for valuable insight, all of you.

It is battery backed-up laptop so I thought it should work well. I've 
met no problems since when I've set up this few years ago. To be hones I 
even forgot I've got this set up :)

I'll lower the value, you're right, that 15 minutes are pretty extreme.

--
Martin