On Wed, Dec 21, 2016 at 4:06 PM, Theodore Ts'o <tytso@xxxxxxx> wrote: > On Wed, Dec 21, 2016 at 04:23:17PM +1100, Dave Chinner wrote: >> It's a philoophical and architectural issue. We currently have a >> distinct separation between generic functionality and per-filesystem >> specific definitions. The on-disk definitions are owned by the >> filesystem not the generic code, and the generic code /never/ sees >> what the filesystem stores on disk. THe VFS is supposed to be >> completely independent of what the filesystems store on disk - it's >> an abstract concept - so that it can morph into whatever is required >> to support the functionality the different filesystem provides. > > I had the same concerns as Dave and Darrick --- which is that it just > "feels" wrong to define file system encoding semantics in generic > code. So it's really much more of a taste issue than anything else. > I'll note that we've already started taking some steps down this > slippery path with the definition of whiteout --- where we define > WHITEOUT_MODE and WHITEOUT_DEV to be 0, and both the generic code and > the file system code need to agree that the on-disk encoding of a > whiteout is an inode with mode S_IFCHR | WHITEOUT_MODE, and with the > device number set to WHITEOUT_DEV. WHITEOUT_DEV is not meant to be an encoding, it's meant to be an API. There are reasons why we didn't want to invent a new kind of object for whiteouts and so the choice fell on some special kind of already existing object type. So it's now a char dev with 0 device number and that's set in stone, at least as far as the userspace API goes. Filesystems are, on the other hand, free to encode this object in whatever way they wish. And in the VFS we could represent it with a new kind of object to be converted to the char dev on the userspace interface, if that turns out to be a better design choice. Thanks, Miklos -- 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
