On Thu, 2009-02-19 at 14:00 -0500, Christoph Hellwig wrote: > On Thu, Feb 19, 2009 at 10:20:07AM -0800, Dave Hansen wrote: > > > > There are plenty of filesystems that are not supported for > > c/r at this point. Think of things like hugetlbfs which > > are externally visible or pipefs which are kernel-internal. > > > > This provides a quick way to make the "normal" filesystems > > which are currently supported. This is also safe if any > > new code gets added. We assume that a fs is non-supported > > unless someone takes explicit action to the contrary. > > > > I bet there are some more filesystems that are OK, but > > these probably cover 99% of the users for now. > > Given that a normal fs should be checkpointable you should > make those exposing internal state, not the other way around.
In general I agree with you. But, I think practicality gets in the way here. Here's the cscope output from file_system_type and FS_REQUIRES_DEV (basically grepping the tree for them): $ wc -l file_system_type FS_REQUIRES_DEV 256 file_system_type 41 FS_REQUIRES_DEV So, (very) roughly 1/6 of the filesystems are the "normal" block-based ones that we all know and love. The rest are ones that I'd have to at the very least think about before saying that they're supported. I guess we could say that FS_REQUIRES_DEV by default implies FS_CHECKPOINTABLE: #define __FS_REQUIRES_DEV 1 #define FS_REQUIRES_DEV (__FS_REQUIRES_DEV|FS_CHECKPOINTABLE) I really don't mind doing it *that* much either way, but I'd sure like to go specifically tag ~40 filesystems rather than 200. -- Dave _______________________________________________ Containers mailing list contain...@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/containers _______________________________________________ Devel mailing list Devel@openvz.org https://openvz.org/mailman/listinfo/devel