Re: [Dump-devel] dump and largefiles

[<ty...@va...>]

   Date: Tue, 19 Dec 2000 12:34:13 +0100
   From: Andrea Arcangeli <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.

The question is whether a binary compiled with LFS support will work on
a non-LFS system.

Also note that if you have a LFS filesystem mounted on a non-LFS system,
ideally something sane should happen.  (Note that this is true for
e2fsprogs/libext2fs; we use the llseek() system call on devices, which
exists even on non-LFS systems.)

   > -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).

If you do things right, you don't need glibc's LFS support.  This is
true for e2fsprogs, and if you use the unix_io interfaces, you should be
fine.

						- Ted