Re: [Dump-devel] dump and largefiles

[Andrea A. <an...@su...>]

On Tue, Dec 19, 2000 at 11:58:42AM +0100, Stelian Pop wrote:
> Does it hurt to use this patch on a non-LFS system ? Even with
> this patch, it will continue to run correctly on a non-LFS system
> I suppose...

Strictly speaking there's the case of a non-LFS system with a largefile into
it. restore won't work (think the truncate for the filesize). I think the
`dump` stage could even work for a non-LFS system as e2fsprogs probably only
accesses the blockdevice via read/write/lseek64.

But you can't do much about that case (other than maybe print a warning
and I was too lazy to care about that ;).

So I'd say yes.

> There must be some configure option in order to enable large file
> support, but only in order to pass -D_FILE_OFFSET_BITS=64 on the
> compile line ? No dynamic compile-time checking for LFS system. 
> Am I wrong here ?

See above, I'd say yes.

> What about binary compatibility ? Will a binary built with

It will be binary compatibile say with glibc 2.2.

> -D_FILE_OFFSET_BITS=64 run correctly on a Linux 2.0/libc5 system
> for example ?

Certainly not, only glibc provides LFS support. glibc will try however to work
also on a non-LFS kernel correctly (but you need the same glibc major revision
and that's of course usual requirement regardless of LFS issues given it's
dynamically linked to it).


Stelian, do you have a regression test suite for dump? Does my patch works
flawlessy for you too? I tested it on a 5G largefile without holes and a 8G
largefile with holes and a few small files.  It worked fine for me but as said
I haven't tested it very extensively (nor I tested e2fsck keeps working,
but that should really keep working ;). If you run a regression test suite
against it please keep me posted (I need some extensive testing on it). Thanks!

Andrea