On 29 Dec 2006, at 00:44, Bryan Henderson wrote:
Plus, in some cases optimization is a matter of
life or death -- the extra resources (storage space, cache space,
access
time, etc) for the duplicated files might be enough to move you from
practical to impractical.
You see this a lot with LiveCDs that use hardlinks to cram as much
information onto a CDROM as possible. People copy the liveCD, lose
the hardlinks, and wonder why their recreated LiveCD filesystem
doesn't fit. In fact, liveCDs are a good example of things which are
difficult to backup with the standard POSIX interface. Most LiveCDs
sort the fles on disk to optimise boot-time, and this sort
information is always lost by copying.
People tend to demand that restore programs faithfully restore what
was
backed up. (I've even seen requirements that the inode numbers upon
restore be the same). Given the difficulty of dealing with multi-
linked
files, not to mention various nonstandard file attributes fancy
filesystem
types have, I suppose they probably don't have really high
expectations of
that nowadays, but it's still a worthy goal not to turn one file
into two.
It is also equally important to not turn two files into one (i.e.
incorrectly make hardlinks of files which are not hardlinks).
Cramfs doesn't support hardlinks, but it does detect duplicates -
duplicates share the file data on disk. Unfortunately, cramfs
computes inode numbers from the file data location, which means two
files with the same data get the same inode number, even if they were
not hardlinks in the original filesystem. If it wasn't for the fact
that cramfs always stores nlink as 1, they would look like hardlinks,
and probably look sufficiently like hardlinks to fool a lot of
applications. Of course as cramfs is a read-only filesystem it
doesn't matter unless the filesystem is copied.
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.
Phillip
-
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
