On 29 Dec 2006, at 08:41, Arjan van de Ven wrote:
I think "statement 2" is extremely important. Without this guarantee
applications have to guess which files are hardlinks. Any guessing
is going to be be got wrong sometimes with potentially disastrous
results.
actually no. Statement 1 will tell them when the kernel knows they are
hardlinks. It's the kernels job to make a reasonably quality of
implementation so that that works most of the time.
Statement 2 requires that "all of the time" which suddenly creates
a lot
of evil corner cases (like "what if I mount a network filesystem twice
and the server doesn't quite tell me enough to figure it out"
cases) to
make it impractical.
Actually no. Statement 2 for me is important in terms of archive
correctness. With my "archiver" program Mksquashfs, if the two files
are the same, and filesystem says they're hardlinks, I make them
hardlinks in the Squashfs filesystem, otherwise they're stored as
duplicates (same data, different inode). Doesn't matter much in
terms of storage overhead, but it does matter if two files become
one, or vice versa.
If a filesystem cannot guarantee statement 2 in the "normal" case, I
wouldn't use hardlinks in that filesystem, period. Using "evil
corner cases" and network filesystems as an objection is somewhat
like saying because we can't do it in every case, we shouldn't bother
doing it in the "normal" case too. Disk based filesystems should be
able to handle statements 1 and 2. No-one expects things to always
work correctly in "evil corner cases" or with network filesystems.
Phillip
Think of it as the difference between good and perfect.
(and perfect is the enemy of good :)
the kernel will tell you when it knows within reason, via statement 1
technology. It's not perfect, but reasonably will be enough for normal
userspace to depend on it. Your case is NOT a case of "I require
100%"..
it's a "we'd like to take hardlinks into account" case.
--
if you want to mail me at work (you don't), use arjan (at)
linux.intel.com
Test the interaction between Linux and your BIOS via http://
www.linuxfirmwarekit.org
-
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
