On Tue, May 29, 2012 at 10:14 AM, Boaz Harrosh <bharrosh@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
