Messages in this thread | | | Date | Wed, 10 Nov 1999 17:40:50 -0500 (EST) | From | Alexander Viro <> | Subject | Re: Getting IOCTL's into VFS File System Drivers |
| |
On Wed, 10 Nov 1999, Jeff V. Merkey wrote:
> > Also, > > Along the same lines, it would be really cool if the fsck capability was > made a part of the VFS as a function call (which is how it is in Windows > 2000 FS drivers), so Linux could have a single FSCK utility that would > do file system fixup on all of the FS's in the kernel, rather than > requiring each FS to provide it's own. In the Microsoft Windows 2000 > Implementation, it's implemented as a single function call that gets > invoked automatically (or manually) when a volume mount fails. They did > it this way so that all their Windows tools would work with the > different file system drivers without having to need a specially written > program for each file system. They also have hooks for file system > defrag, and backup/restore integrated into their IFS. If we could > extend the VFS to do the same types of things, it would mean Linux would > only need a single set of "generic" file system repair, defrag, and > backup/restore utilities that would work with all the FS drivers in > Linux. > > Just a suggestion.
What will it buy? You still have to write all this code. You still can't (and shouldn't) do it on a filesystem that is mounted r/w. This code can be equally easy placed into userspace (where it _is_ now). It doesn't give you any win in fsck(8) (it's _not_ in ALL CAPS, BTW), since the current fsck _already_ doesn't care for filesystem layout - it just calls an appropriate fsck.<something>.
All the difference you'll get will be that e2fsck will be moved into fs/ext2, fsck.minix - into fs/minix, etc. I.e. complexity is the same, except that the code will (a) permanently in core and (b) any bug will bcome more dangerous, since you are in ring 0.
So the question being: What For? We already have generic fsck. It sits in /sbin/fsck. We already have generic mkfs (/sbin/mkfs). What's the reason to move large chucks of code that feels perfectly OK in userland into the kernel? Automagical fsck upon mount? It's a bug, not a feature. That decision belongs to admin. Even if you want it (always want it, that is) you can trivially do it in mount(8) or in the script that calls mount.
If NT really does what you describe... Well, small wonder that it's so bloated.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |