Re: attacking btrfs filesystems via UUID collisions?

On Mon, 2015-12-14 at 14:26 -0700, Chris Murphy wrote: > The automobile is invented and due to the ensuing chaos, common > practice of doing whatever the F you wanted came to an end in favor > of > rules of the road and traffic lights. I'm sure some people went > ballistic, but for the most part

Re: [PATCH v2 1/2] btrfs: Enhance super validation check

David Sterba wrote on 2015/12/14 17:24 +0100: On Tue, Dec 08, 2015 at 03:35:57PM +0800, Qu Wenruo wrote: @@ -4005,31 +3989,47 @@ static int btrfs_check_super_valid(struct btrfs_fs_info *fs_info, } /* -* The common minimum, we don't know if we can trust the

Re: dear developers, can we have notdatacow + checksumming, plz?

On Mon, 2015-12-14 at 17:42 +1100, Russell Coker wrote: > My understanding of BTRFS is that the metadata referencing data > blocks has the > checksums for those blocks, then the blocks which link to that > metadata (EG > directory entries referencing file metadata) has checksums of those. You

Re: btrfs: poor performance on deleting many large files

Le 15/12/2015 02:49, Duncan a écrit : > Christoph Anton Mitterer posted on Tue, 15 Dec 2015 00:25:05 +0100 as > excerpted: > >> On Mon, 2015-12-14 at 22:30 +0100, Lionel Bouton wrote: >> >>> I use noatime and nodiratime >> FYI: noatime implies nodiratime :-) > Was going to post that myself. Is

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

Laurent Bonnaud wrote on 2015/12/14 13:47 +0100: On 11/12/2015 15:21, Laurent Bonnaud wrote: The next step will we to run a "btrfs scrub" to check if data loss did happen... Scrubbing is now finished and it detected no errors. Glad to hear that. Your fs should be OK now. Thanks, Qu

Re: !PageLocked BUG_ON hit in clear_page_dirty_for_io

On Mon, Dec 14, 2015 at 07:03:24PM -0500, Chris Mason wrote: > On Tue, Dec 08, 2015 at 11:25:28PM -0500, Dave Jones wrote: > > Not sure if I've already reported this one, but I've been seeing this > > a lot this last couple days. > > > > kernel BUG at mm/page-writeback.c:2654! > > invalid opcode:

Re: [PATCH v3] btrfs: Introduce new mount option to disable tree log replay

On Mon, 2015-12-14 at 15:20 -0500, Austin S. Hemmelgarn wrote: > On 2015-12-14 14:44, Christoph Anton Mitterer wrote: > > On Mon, 2015-12-14 at 14:33 -0500, Austin S. Hemmelgarn wrote: > > > The traditional reasoning was that read-only meant that users > > > couldn't > > > change anything > >

[PATCH v2] btrfs-progs: Enhance chunk validation check

Enhance chunk validation: 1) Num_stripes We already have such check but it's only in super block sys chunk array. Now check all on-disk chunks. 2) Chunk logical It should be aligned to sector size. This behavior should be *DOUBLE CHECKED* for 64K sector size like PPC64 or

Re: btrfs: poor performance on deleting many large files

Christoph Anton Mitterer posted on Tue, 15 Dec 2015 00:25:05 +0100 as excerpted: > On Mon, 2015-12-14 at 22:30 +0100, Lionel Bouton wrote: > >> I use noatime and nodiratime > FYI: noatime implies nodiratime :-) Was going to post that myself. Is there some reason you: a) use nodiratime when

Re: !PageLocked BUG_ON hit in clear_page_dirty_for_io

On Tue, Dec 08, 2015 at 11:25:28PM -0500, Dave Jones wrote: > Not sure if I've already reported this one, but I've been seeing this > a lot this last couple days. > > kernel BUG at mm/page-writeback.c:2654! > invalid opcode: [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN We ended up discussing this

Re: attacking btrfs filesystems via UUID collisions?

On Mon, 2015-12-14 at 13:55 -0700, Chris Murphy wrote: > I'm aware of this proof of concept. I'd put it, and this one, in the > realm of a targeted attack, so it's not nearly as likely as other > problems needing fixing. That doesn't mean don't understand it better > so it can be fixed. It means

[PATCH v3 2/2] btrfs: Enhance chunk validation check

Enhance chunk validation: 1) Num_stripes We already have such check but it's only in super block sys chunk array. Now check all on-disk chunks. 2) Chunk logical It should be aligned to sector size. This behavior should be *DOUBLE CHECKED* for 64K sector size like PPC64 or

[PATCH v3 1/2] btrfs: Enhance super validation check

Enhance btrfs_check_super_valid() function by the following points: 1) Restrict sector/node size check Not the old max/min valid check, but also check if it's a power of 2. So some bogus number like 12K node size won't pass now. 2) Super flag check For now, there is still some

Re: attacking btrfs filesystems via UUID collisions?

On Mon, 2015-12-14 at 08:23 -0500, Austin S. Hemmelgarn wrote: > The reason that this isn't quite as high of a concern is because > performing this attack requires either root access, or direct > physical > access to the hardware, and in either case, your system is already > compromised. No

Re: Will "btrfs check --repair" fix the mounting problem?

Ivan Sizov wrote on 2015/12/14 20:55 +0300: 2015-12-14 5:28 GMT+03:00 Qu Wenruo : Not completely sure, but it may be related to a regression in 4.2. The regression it self is already fixed, but is not backported to 4.2 as far as I know. So, I'd recommend to revert to

Re: btrfs: poor performance on deleting many large files

Austin S. Hemmelgarn posted on Mon, 14 Dec 2015 15:27:11 -0500 as excerpted: > FWIW, both Duncan and I have our own copy of the sources patched to > default to noatime, and I know a number of embedded Linux developers who > do likewise, and I've even heard talk in the past of some distributions >

[PATCH] Btrfs: do not create empty block group if we have allocated data

Now we force to create empty block group to keep data profile alive, however, in the below example, we eventually get an empty block group while we're trying to get more space for other types (metadata/system), - Before, block group "A": size=2G, used=1.2G block group "B": size=2G, used=512M -

Re: dear developers, can we have notdatacow + checksumming, plz?

On Mon, 2015-12-14 at 09:16 -0500, Austin S. Hemmelgarn wrote: > > When one starts to get a bit deeper into btrfs (from the admin/end- > > user > > side) one sooner or later stumbles across the recommendation/need > > to > > use nodatacow for certain types of data (DBs, VM images, etc.) and > >

Re: [auto-]defrag, nodatacow - general suggestions?(was: btrfs: poor performance on deleting many large files?)

Christoph Anton Mitterer posted on Mon, 14 Dec 2015 02:44:55 +0100 as excerpted: > Two more on these: > > On Thu, 2015-11-26 at 00:33 +, Hugo Mills wrote: >> 3) When I would actually disable datacow for e.g. a subvolume that >> > holds VMs or DBs... what are all the implications? >> After

Re: [auto-]defrag, nodatacow - general suggestions?(was: btrfs: poor performance on deleting many large files?)

Christoph Anton Mitterer posted on Mon, 14 Dec 2015 03:46:01 +0100 as excerpted: >> Same here.  In fact, my most anticipated feature is N-way-mirroring, > Hmm ... not totally sure about that... > AFAIU, N-way-mirroring is what currently the currently wrongly called > RAID1 is in btrfs, i.e.

Re: Kernel lockup, might be helpful log.

Hugo Mills posted on Mon, 14 Dec 2015 08:35:24 + as excerpted: > It's not just btrfs. Invalid opcode is the way that the kernel's BUG and > BUG_ON macro is implemented. Thanks. I indicated that I suspected broader kernel use further down the reply, but it's very nice to have confirmation,

RE: freeze_bdev and scrub/re-balance

Thank you liubo for your reply. But I am very clear with your meaning of "It should be like that with COW enabled" I'd like to confirm, if defragment/scrub/rebalance is in progress, and my code calls "freeze_bdev" (in kernel code, or in user space code via ioctl), I can get a consistent file

Re: Still not production ready

Qu Wenruo posted on Mon, 14 Dec 2015 15:32:02 +0800 as excerpted: > Oh, my poor English... :( Well, as I said, native English speakers commonly enough mis-negate... The real issue seems to be that English simply lacks proper support for the double-negatives feature that people keep wanting to

Re: btrfs check inconsistency with raid1, part 1

Chris Murphy posted on Mon, 14 Dec 2015 00:24:21 -0700 as excerpted: >> Personally speaking, it may be a false alert from btrfsck. >> So in this case, I can't provide much help. >> >> If you're brave enough, mount it rw to see what will happen(although it >> may mount just OK). > > I'm brave

Re: bad extent [5993525264384, 5993525280768), type mismatch with chunk

On 11/12/2015 15:21, Laurent Bonnaud wrote: > The next step will we to run a "btrfs scrub" to check if data loss did > happen... Scrubbing is now finished and it detected no errors. -- Laurent. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message

safety of journal based fs (was: Re: still kworker at 100% cpu…)

Hi! Using a different subject for the journal fs related things which are off topic, but still interesting. Might make sense to move to fsdevel-ml or ext4/ XFS mailing lists? Otherwise, I suggest we focus on BTRFS here. Still wanted to reply. Am Montag, 14. Dezember 2015, 16:48:58 CET schrieb

Re: Kernel lockup, might be helpful log.

On Sun, Dec 13, 2015 at 10:55 PM, Birdsarenice wrote: > I've finally finished deleting all those nasty unreliable Seagate drives > from my array. During the process I crashed my server - over, and over, and > over. Completely gone - screen blank, controls unresponsive, no

Re: btrfs: poor performance on deleting many large files

On Mon, Dec 14, 2015 at 7:24 AM, Austin S. Hemmelgarn wrote: > > If you have software that actually depends on atimes, then that software is > broken (and yes, I even feel this way about Mutt). The way atimes are > implemented on most systems breaks the semantics that

Re: attacking btrfs filesystems via UUID collisions?

On 2015-12-13 19:27, Christoph Anton Mitterer wrote: On Fri, 2015-12-11 at 16:06 -0700, Chris Murphy wrote: For anything but a new and empty Btrfs volume What's the influence of the fs being new/empty? this hypothetical attack would be a ton easier to do on LVM and mdadm raid because they

Re: dear developers, can we have notdatacow + checksumming, plz?

On 2015-12-13 23:59, Christoph Anton Mitterer wrote: (consider that question being asked with that face on: http://goo.gl/LQaOuA) Hey. I've had some discussions on the list these days about not having checksumming with nodatacow (mostly with Hugo and Duncan). They both basically told me it

Re: btrfs: poor performance on deleting many large files

On 2015-12-12 17:15, Christoph Anton Mitterer wrote: On Sat, 2015-11-28 at 06:49 +, Duncan wrote: Christoph Anton Mitterer posted on Sat, 28 Nov 2015 04:57:05 +0100 as excerpted: Still, specifically for snapshots that's a bit unhandy, as one typically doesn't mount each of them... one

Re: [PATCH 2/4] vfs: pull btrfs clone API to vfs layer

On Wed, Dec 09, 2015 at 12:40:33PM -0800, Darrick J. Wong wrote: > I tried this patch series on ppc64 (w/ 32-bit powerpc userland) and I think > it needs to fix up the compat ioctl to make the vfs call... Might need a proper signoff for Al, unless he wants to directly fold it.. -- To unsubscribe

Re: [PATCH] btrfs-progs: Enhance chunk validation check

On Tue, Dec 08, 2015 at 05:05:22PM +0800, Qu Wenruo wrote: > +#define IS_ALIGNED(x, a)(((x) & ((typeof(x))(a) - 1)) == 0) > + > +static inline int is_power_of_2(unsigned long n) > +{ > + return (n != 0 && ((n & (n - 1)) == 0)); > +} Please move them to kerncompat.h -- To

[PATCH] Btrfs: use linux/sizes.h to represent constants

We use many constants to represent size and offset value. And to make code readable we use '256 * 1024 * 1024' instead of '268435456' to represent '256MB'. However we can make far more readable with 'SZ_256MB' which is defined in the 'linux/sizes.h'. So this patch replaces 'xxx * 1024 * 1024'

Re: [PATCH v3] btrfs: Introduce new mount option to disable tree log replay

On Thu, Dec 10, 2015 at 10:34:06AM +0800, Qu Wenruo wrote: > Introduce a new mount option "nologreplay" to co-operate with "ro" mount > option to get real readonly mount, like "norecovery" in ext* and xfs. > > Since the new parse_options() need to check new flags at remount time, > so add a new

Re: [PATCH v2 1/2] btrfs: Enhance super validation check

On Tue, Dec 08, 2015 at 03:35:57PM +0800, Qu Wenruo wrote: > @@ -4005,31 +3989,47 @@ static int btrfs_check_super_valid(struct > btrfs_fs_info *fs_info, > } > > /* > - * The common minimum, we don't know if we can trust the > nodesize/sectorsize > - * items yet, they'll

[PATCH 5/4] vfs: return EINVAL for unsupported file types in clone

Signed-off-by: Christoph Hellwig diff --git a/fs/read_write.c b/fs/read_write.c index 1f0d3f1..6268ebc 100644 --- a/fs/read_write.c +++ b/fs/read_write.c @@ -1528,7 +1528,7 @@ int vfs_clone_file_range(struct file *file_in, loff_t pos_in, if (S_ISDIR(inode_in->i_mode) ||

Re: [PATCH] Btrfs: use linux/sizes.h to represent constants

On Tue, Dec 15, 2015 at 01:42:10AM +0900, Byongho Lee wrote: > We use many constants to represent size and offset value. And to make > code readable we use '256 * 1024 * 1024' instead of '268435456' to > represent '256MB'. However we can make far more readable with 'SZ_256MB' > which is defined

Re: [PATCH 2/4] vfs: pull btrfs clone API to vfs layer

On Wed, Dec 09, 2015 at 12:40:33PM -0800, Darrick J. Wong wrote: > On Thu, Dec 03, 2015 at 12:59:50PM +0100, Christoph Hellwig wrote: > > The btrfs clone ioctls are now adopted by other file systems, with NFS > > and CIFS already having support for them, and XFS being under active > > development.

Re: [4.3-rc4] scrubbing aborts before finishing

[...] >> > merkaba:~> btrfs fi sh /daten >> > Label: 'daten' uuid: […] >> > >> > Total devices 1 FS bytes used 227.23GiB >> > devid1 size 230.00GiB used 230.00GiB path [...] >> > merkaba:~> btrfs fi df /daten >> > Data, single: total=228.99GiB, used=226.79GiB >> > System,

Re: attacking btrfs filesystems via UUID collisions?

On Mon, Dec 14, 2015 at 6:23 AM, Austin S. Hemmelgarn wrote: > > Agreed, if yo9u can't substantiate _why_ it's bad practice, then you aren't > making a valid argument. The fact that there is software that doesn't > handle it well would say to me based on established

Re: btrfs: poor performance on deleting many large files

Le 14/12/2015 21:27, Austin S. Hemmelgarn a écrit : > AFAIUI, the _only_ reason that that is still the default is because of > Mutt, and that won't change as long as some of the kernel developers > are using Mutt for e-mail and the Mutt developers don't realize that > what they are doing is

Re: [PATCH v3] btrfs: Introduce new mount option to disable tree log replay

On 2015-12-14 14:44, Christoph Anton Mitterer wrote: On Mon, 2015-12-14 at 14:33 -0500, Austin S. Hemmelgarn wrote: The traditional reasoning was that read-only meant that users couldn't change anything Where I'd however count the atime changes to. The atimes wouldn't change magically, but

Re: btrfs: poor performance on deleting many large files

On 2015-12-14 14:39, Christoph Anton Mitterer wrote: On Mon, 2015-12-14 at 09:24 -0500, Austin S. Hemmelgarn wrote: Unless things have changed very recently, even many modern systems update atime on read-only filesystems, unless the media itself is read-only. Seriously? Oh... *sigh*... You

Re: Still not production ready

On 2015-12-14 14:08, Chris Murphy wrote: On Mon, Dec 14, 2015 at 5:10 AM, Duncan <1i5t5.dun...@cox.net> wrote: Qu Wenruo posted on Mon, 14 Dec 2015 15:32:02 +0800 as excerpted: Oh, my poor English... :( Well, as I said, native English speakers commonly enough mis-negate... The real issue

Re: [4.3-rc4] scrubbing aborts before finishing

On Mon, Dec 14, 2015 at 6:31 PM, Henk Slager wrote: > [...] >>> > merkaba:~> btrfs fi sh /daten >>> > Label: 'daten' uuid: […] >>> > >>> > Total devices 1 FS bytes used 227.23GiB >>> > devid1 size 230.00GiB used 230.00GiB path > [...] >>> > merkaba:~> btrfs

Re: Still not production ready

On Mon, Dec 14, 2015 at 5:10 AM, Duncan <1i5t5.dun...@cox.net> wrote: > Qu Wenruo posted on Mon, 14 Dec 2015 15:32:02 +0800 as excerpted: > >> Oh, my poor English... :( > > Well, as I said, native English speakers commonly enough mis-negate... > > The real issue seems to be that English simply

btrfs-progs: enhanced btrfsck progress patch proposition

Hi, I've been forking btrfs-progs locally to add an enhanced progress indicator, based on the work from Silvio Fricke posted here in September. I'm using it routinely, it has been of help when I was debugging my multi-Tb btrfs system, where I often had to use btrfs check. So I thought it

Re: btrfs: poor performance on deleting many large files

On Mon, 2015-12-14 at 09:24 -0500, Austin S. Hemmelgarn wrote: > Unless things have changed very recently, even many modern systems > update atime on read-only filesystems, unless the media itself is > read-only. Seriously? Oh... *sigh*... You mean as in Linux, ext*, xfs? > If you have software

Re: [PATCH v3] btrfs: Introduce new mount option to disable tree log replay

On Mon, 2015-12-14 at 18:32 +0100, David Sterba wrote: > I've read the discussions around the change and from the user's POV > I'd > suggest to add another mount option that would be just an alias for > any > mount options that would implement the 'hard-ro' semantics. Nice to hear...  > Say it's

Re: [PATCH v3] btrfs: Introduce new mount option to disable tree log replay

On Mon, 2015-12-14 at 12:50 -0500, Austin S. Hemmelgarn wrote: > It should also imply noatime.  I'm not sure how BTRFS handles atime > when > mounted RO, but I know a lot of old UNIX systems updated atime even > on > filesystems mounted RO, and I know that at least at one point Linux > did too.

Re: [PATCH v3] btrfs: Introduce new mount option to disable tree log replay

On 2015-12-14 14:16, Christoph Anton Mitterer wrote: On Mon, 2015-12-14 at 12:50 -0500, Austin S. Hemmelgarn wrote: It should also imply noatime. I'm not sure how BTRFS handles atime when mounted RO, but I know a lot of old UNIX systems updated atime even on filesystems mounted RO, and I know

Re: [PATCH v3] btrfs: Introduce new mount option to disable tree log replay

On Mon, 2015-12-14 at 14:33 -0500, Austin S. Hemmelgarn wrote: > The traditional reasoning was that read-only meant that users > couldn't > change anything Where I'd however count the atime changes to. The atimes wouldn't change magically, but only because the user stared some program, configured

Re: [PATCH v3] btrfs: Introduce new mount option to disable tree log replay

On 2015-12-14 12:32, David Sterba wrote: On Thu, Dec 10, 2015 at 10:34:06AM +0800, Qu Wenruo wrote: Introduce a new mount option "nologreplay" to co-operate with "ro" mount option to get real readonly mount, like "norecovery" in ext* and xfs. Since the new parse_options() need to check new

Re: Will "btrfs check --repair" fix the mounting problem?

2015-12-14 5:28 GMT+03:00 Qu Wenruo : > Not completely sure, but it may be related to a regression in 4.2. > The regression it self is already fixed, but is not backported to 4.2 as far > as I know. > > So, I'd recommend to revert to 4.1 and see if things get better. >

Re: btrfs check inconsistency with raid1, part 1

On Mon, Dec 14, 2015 at 1:04 AM, Qu Wenruo wrote: > > > Chris Murphy wrote on 2015/12/14 00:24 -0700: >> What is a full disk dump? I can try to see if it's possible. > > > Just a dd dump. OK, yeah. That's 750GB per drive. >t won't be an easy > thing to find a place to

still kworker at 100% cpu in all of device size allocated with chunks situations with write load (was: Re: Still not production ready)

Am Sonntag, 13. Dezember 2015, 15:19:14 CET schrieb Marc MERLIN: > On Sun, Dec 13, 2015 at 11:35:08PM +0100, Martin Steigerwald wrote: > > Hi! > > > > For me it is still not production ready. Again I ran into: > > > > btrfs kworker thread uses up 100% of a Sandybridge core for minutes on > >

Re: [4.3-rc4] scrubbing aborts before finishing

Am Mittwoch, 25. November 2015, 16:35:39 CET schrieben Sie: > Am Samstag, 31. Oktober 2015, 12:10:37 CET schrieb Martin Steigerwald: > > Am Donnerstag, 22. Oktober 2015, 10:41:15 CET schrieb Martin Steigerwald: > > > I get this: > > > > > > merkaba:~> btrfs scrub status -d / > > > scrub status

Re: btrfs check inconsistency with raid1, part 1

Chris Murphy wrote on 2015/12/14 00:24 -0700: Thanks for the reply. On Sun, Dec 13, 2015 at 10:48 PM, Qu Wenruo wrote: Chris Murphy wrote on 2015/12/13 21:16 -0700: btrfs check with devid 1 and 2 present produces thousands of scary messages, e.g. checksum verify

still kworker at 100% cpu in all of device size allocated with chunks situations with write load (was: Re: Still not production ready)

Am Montag, 14. Dezember 2015, 10:08:16 CET schrieb Qu Wenruo: > Martin Steigerwald wrote on 2015/12/13 23:35 +0100: > > Hi! > > > > For me it is still not production ready. > > Yes, this is the *FACT* and not everyone has a good reason to deny it. > > > Again I ran into: > > > > btrfs kworker

Re: Kernel lockup, might be helpful log.

I've no need for a fix. I know exactly what the underlying cause is: Those Seagate 8TB Archive drives and their known compatibility issues with some kernel versions. I just shared the log because it's a situation that btrfs handles very, very poorly, and the error handling could be improved.

Re: attacking btrfs filesystems via UUID collisions?

On Sun, Dec 13, 2015 at 5:27 PM, Christoph Anton Mitterer wrote: > On Fri, 2015-12-11 at 16:06 -0700, Chris Murphy wrote: >> For anything but a new and empty Btrfs volume > What's the influence of the fs being new/empty? > >> this hypothetical >> attack would be a ton

Re: Kernel lockup, might be helpful log.

On Mon, Dec 14, 2015 at 06:51:41AM +, Duncan wrote: > Birdsarenice posted on Sun, 13 Dec 2015 22:55:19 + as excerpted: > > > Meanwhile, I did get lucky: At one crash I happened to be logged in and > > was able to hit dmesg seconds before it went completely. So what I have > > here is

Re: still kworker at 100% cpu in all of device size allocated with chunks situations with write load

Martin Steigerwald wrote on 2015/12/14 09:18 +0100: Am Montag, 14. Dezember 2015, 10:08:16 CET schrieb Qu Wenruo: Martin Steigerwald wrote on 2015/12/13 23:35 +0100: Hi! For me it is still not production ready. Yes, this is the *FACT* and not everyone has a good reason to deny it. Again

Re: still kworker at 100% cpu in all of device size allocated with chunks situations with write load

Hi Qu. I reply to the journal fs things in a mail with a different subject. Am Montag, 14. Dezember 2015, 16:48:58 CET schrieb Qu Wenruo: > Martin Steigerwald wrote on 2015/12/14 09:18 +0100: > > Am Montag, 14. Dezember 2015, 10:08:16 CET schrieb Qu Wenruo: > >> Martin Steigerwald wrote on

Re: btrfs: poor performance on deleting many large files

On Mon, 2015-12-14 at 15:27 -0500, Austin S. Hemmelgarn wrote: > On 2015-12-14 14:39, Christoph Anton Mitterer wrote: > > On Mon, 2015-12-14 at 09:24 -0500, Austin S. Hemmelgarn wrote: > > > Unless things have changed very recently, even many modern > > > systems > > > update atime on read-only

project idea: per-object default mount-options / more btrfs-properties / chattr attributes (was: btrfs: poor performance on deleting many large files)

Just FYI: On Mon, 2015-12-14 at 15:27 -0500, Austin S. Hemmelgarn wrote: > > My idea would be basically, that having a noatime btrfs-property, > > which > > is perhaps even set automatically, would be an elegant way of doing > > that. > > I just haven't had time to properly write that up and add

Re: btrfs: poor performance on deleting many large files

On Mon, 2015-12-14 at 22:30 +0100, Lionel Bouton wrote: > Mutt is often used as an example but tmpwatch uses atime by default > too > and it's quite useful. Hmm one could probably argue that these few cases justify the use of separate filesystems (or btrfs subvols ;) ), so that the majority could