Re: ENOSPC while creating snapshot

[Duncan <1i5t5.duncan@cox.net>]

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.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman