> You should also be aware that if you try to read an e2compr'd
> disk/harddisk on a box without an e2compr'd kernel, everything will
> work ok, but your data will be corrupted, since it never gets
> decompressed.
David Woodhouse replies:
: Are you sure? Compression is an incompatible feature in the bitmap, so doesn't
: that mean 'normal' kernels will refuse to mount it?
Ian says that he used e2compr in the 2.0 days, and what he says is
true for that time.
Even in e2compr-0.4 times, I was raising the
EXT2_FEATURE_INCOMPAT_COMPRESSION bit but wasn't bumping the
filesystem revision number to 1; so the kernel was just ignoring the
incompat bit.
(A bug report I'm looking at suggests that even now I'm doing
something wrong, though I haven't been able to reproduce the problem.
Discussion continues.)
> It's also a very, very bad idea to run e2compr on an older drive, or a
> drive with bad blocks, since if the drive starts going bad, you lose
> more data than on an uncompressed drive.
Well, yes, you would only lose more data from the same file. E2compr
never uses the same block to hold data from more than one file (unless
you count hard links, of course). So instead of losing 1KB of data
from a file, you could lose up to 32KB from that file.
That said, the current code is a bit lazy about error handling, so bad
disks might be asking for trouble. Ext2fs has never been especially
friendly/paranoid about bad hardware (a bad filesystem can in some
cases cause a kernel panic even without e2compr), but I'm sure e2compr
makes things worse.
pjm.
-
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/