[lkml]   [2012]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: atime and filesystems with snapshots (especially Btrfs)
On Tue, May 29, 2012 at 10:14 AM, Boaz Harrosh <> wrote:
> Sounds like a real problem. I would suggest a few remedies.
> 1. Make a filesystem persistent parameter that says noatime/relatime/atime
>   So the default if not specified on mount is taken as a property of
>   the FS (mkfs can set it)
That would be possible. But again, I'm not sure if it is allowed for
one fs type to
differ from all the other filesystems in its default behavior.
> 2. The snapshot program should check and complain if it is on, and recommend
>   an off. Since the problem only starts with a snapshot.
That would definitely cause awareness for the problem and many people would
probably switch to noatime on mount.
> 3. If space availability drops under some threshold, disable atime. As you said
>   this is catastrophic in this case. So user can always search and delete files.
>   In fact if the IO was only because of atime, it should be a soft error, warned,
>   and ignored.
It would be hard to determine a good threshold. This really depends on the way
snapshots are used.
> But perhaps the true solution is to put atime on a side table, so only the atime
> info gets COW and not the all MetaData
This would definitely reduce the problem to a minimum. But it may be harder
to implement as it sounds. You would either have to keep 2 trees per subvolume
(one for the fs and one for atime) or share one tree for all subvols.
I don't think
2 trees per subvolume would be acceptable, but I'm not sure. A shared tree
would require to implement some kind of custom refcounting for the items, as
changes to one fs tree should not change atime of the other and thus create
new items on demand. It would probably also require snapshot origin tracking,
because on a freshly snapshotted subvolume, no atime entries would exist at
all and must be read from the parent/origin.
> Just my $0.017
> Boaz
>> Alex.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
>> the body of a message to
>> More majordomo info at
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2012-05-29 16:41    [W:0.106 / U:2.916 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site