| |||||||||||||
The two sides of reflink()The two sides of reflink()Posted May 11, 2009 7:37 UTC (Mon) by giraffedata (subscriber, #1954)In reply to: The two sides of reflink() by nix Parent article: The two sides of reflink()
What? Directory entries and inodes aren't tied together in the fs model at all, except that each directory entry increases i_nlink in the corresponding inode by one. That's a pretty tight bond, especially since i_nlink controls when the inode/file gets deleted. Also, you can't make the kernel create an inode without also creating a directory entry, and except temporarily, an inode cannot exist without at least one directory entry associated with it. Those are the bonds that it would be nice to get away from, as pretty much every OS except Unix does.
Reflinks simply would ... We must be talking about different things. I was just talking about what Unix should do instead of what it always has (as a fundamental design point) done. Nothing to do with reflinks. And I'm also not claiming it would be compatible with any existing Unix application, but I do believe every application could be done at least as well with a kernel without automatic file deletion and directories.
(Log in to post comments)
The two sides of reflink() Posted May 11, 2009 18:32 UTC (Mon) by nix (subscriber, #2304) [Link]
*And directories*? You're dreaming. Directories are in practice essential
for scalability. If they weren't in the kernel, they'd need to be in some userspace library (ew).
The two sides of reflink() Posted May 12, 2009 1:22 UTC (Tue) by giraffedata (subscriber, #1954) [Link] If they weren't in the kernel, they'd need to be in some userspace library (ew). They work better in user space -- there's more flexibility there and the basic concept of a directory has nothing to do with resource allocation between users, which is what the kernel is for. Many OSes do them outside the kernel. The only reason they have to be in the kernel in Unix is that the kernel deletes files implicitly based on directory references. And as I've been saying, we'd be better off without that.
The two sides of reflink() Posted May 12, 2009 19:59 UTC (Tue) by nix (subscriber, #2304) [Link]
Putting directories outside the kernel also means that a whole pile of
things POSIX guarantees become, as near I can tell, impossible to provide. I can't see any way to keep cross-directory rename() atomic, for instance.
Also it's a grotesque security hole: now you can't keep stuff secret by
Periodically there are proposals to introduce an open()-by-inode-number
(And if you're going to go that route, make the inums 1024 bits long and
|
|||||||||||||