Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
The two sides of reflink()
Posted May 10, 2009 1:45 UTC (Sun) by giraffedata (subscriber, #1954)
Assuming they have the necessary privileges to do so, obviously.
Well not obviously, since that assumption leaves the situation equally weird.
But now that you've said that's what you have in mind, maybe you can elaborate. Would an unprivileged person be able to use reflink? What would happen if he did it on a file he doesn't own? Would it be possible for someone to create a file he can't access? One whose space is charged to someone else?
Posted May 10, 2009 10:30 UTC (Sun) by nix (subscriber, #2304)
Posted May 10, 2009 18:03 UTC (Sun) by giraffedata (subscriber, #1954)
Posted May 10, 2009 18:36 UTC (Sun) by nix (subscriber, #2304)
(I'd be rather annoyed, too: I use hardlinks all the time.)
Posted May 11, 2009 5:50 UTC (Mon) by giraffedata (subscriber, #1954)
I suspect that if you actually tried to scrap link() et al, a million MTA
authors would try to kill you.
Well, I wouldn't scrap link() et al -- I'd just move them out of the kernel and add the ability to explicitly create and delete files independent of directory links.
Posted May 11, 2009 6:10 UTC (Mon) by nix (subscriber, #2304)
Posted May 11, 2009 5:42 UTC (Mon) by butlerm (subscriber, #13312)
Posted May 11, 2009 5:57 UTC (Mon) by giraffedata (subscriber, #1954)
That would be the direct
consequence of discarding the directory entry / inode distinction in Unix -
But what I described makes the distinction even larger. Today directory entries and inodes are tied together tightly by the kernel.
But I'm curious about how this affects having to reboot when you update system software.
Posted May 11, 2009 6:09 UTC (Mon) by nix (subscriber, #2304)
You could no longer rely on unlink() decrementing i_nlink, but I don't
know of *anything* that depends on this (some things doubtless do but it
can't be common).
It breaks updating running software because that involves unlinking files
that are in use, and because the update process generally consists of
creating a file with a temporary name, filling it out, and rename()ing it
over the original (that's an implicit unlink right there, and it does not
fail). If you break that you break every package manager on the face of
Posted May 11, 2009 7:37 UTC (Mon) by giraffedata (subscriber, #1954)
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.
Posted May 11, 2009 18:32 UTC (Mon) by nix (subscriber, #2304)
Posted May 12, 2009 1:22 UTC (Tue) by giraffedata (subscriber, #1954)
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.
Posted May 12, 2009 19:59 UTC (Tue) by nix (subscriber, #2304)
Also it's a grotesque security hole: now you can't keep stuff secret by
hiding it in unreadable directories anymore.
Periodically there are proposals to introduce an open()-by-inode-number
syscall. They are always shot down. I don't know what sort of system
you're thinking of, but it isn't Unix.
(And if you're going to go that route, make the inums 1024 bits long and
bingo, you've got a capability-based system.)
Posted May 11, 2009 15:38 UTC (Mon) by butlerm (subscriber, #13312)
Posted May 11, 2009 5:34 UTC (Mon) by butlerm (subscriber, #13312)
Otherwise you would get a highly restricted operation that would only be
useful to unprivileged users for making efficient copies of files they
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds