SCIENTIFIC-LINUX-USERS Archives

October 2005

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Steven J. Yellin" <[log in to unmask]>
Reply To:
Steven J. Yellin
Date:
Mon, 17 Oct 2005 11:04:16 -0700
Content-Type:
TEXT/PLAIN
Parts/Attachments:
TEXT/PLAIN (91 lines)
    Here's what I found experimenting with copying sparse files under
3.0.4.

dd: Copies sparse files into non-sparse ones.  A file that takes
    only a small amount of disk space is copied into one that
    may take a large amount.
cp: By default it copies sparse files into sparse files.
rsync: Its default has the same problem as dd -- it copies sparse
    files into what may be much bigger non-sparse ones.  But with
    the "-S" option it does the right thing with sparse files.
tar:  Like rsync, including requiring the "-S" option.

    For large enough sparse files, cp, rsync -S, and tar -S may
not be practical.  The copy can take a very long time even without
much data in the file.  Unless something can be done to make cp,
rsync -S, and tar -S smarter, it will helpful for software (like
nfs-utils in 4.1) to be fixed to refrain from making sparse files
huge.

Steven Yellin

On Mon, 17 Oct 2005, Troy Dawson wrote:

> Hi,
> It's good to see this is (hopefully) already addressed with Update 2.
>
> Just for fun, here is what it looks like on my system.  And by the way,
> I found this out when doing an rsync that had taken over 15 minutes on
> one file.  I think rsync is smart with sparse files, but I believe this
> was just a bit too large for it.
>
> This is on a S.L. 4.1 x86_64 system.  I used the -h on everything,
> because I just love to see a T
>
> Let's look at the file giving me trouble
>      # ls -lh /var/log/lastlog
>      -r--------  1 root root 1.2T Oct 17 08:51 /var/log/lastlog
>
> Yipes, that can't be right.  I've never seen a T for a size before.
>      # ls -l /var/log/lastlog
>      -r--------  1 root root 1254130450140 Oct 17 08:51 /var/log/lastlog
>
> That's huge, but I didn't know I had that big of a filesystem
>      # df -h /var/log/lastlog
>      Filesystem            Size  Used Avail Use% Mounted on
>      /dev/sda1              19G   14G  3.6G  80% /
>
> Wait, how can a 1.2 Terrabyte file fit it 19 Gig, let's look at it's
> real size
>      # du -h /var/log/lastlog
>      60K     /var/log/lastlog
>
> Whew ... that's better.
>
> I think this machine is a good candidate to see if the fix works or not.
> (I'll let you know later today if it did or not.)
> Troy
>
> Jaroslaw Polok wrote:
> > Hi all.
> >
> >>
> >> File /var/log/lastlog very big 1.3 GB, possible a Bug in SL 4.1 X86_64
> >> Version
> >>
> >
> > This shall be corrected by this bugfix:
> >
> > https://rhn.redhat.com/errata/RHBA-2005-727.html :
> >
> > [...]
> > Installing the nfs-utils package turned /var/log/lastlog into a large
> > sparse file. Subsequently, lastlog took a long time to run because
> > nfs-utils used adduser to install the nfsnobody account.
> > [...]
> >
> > Corrected nfs-utils-1.0.6-65.EL4 shall be available soon
> > from SL 4 bugfix area (and integrated in 4.2 I believe)
> >
> > Best Regards
> >
> > Jarek
>
>
> --
> __________________________________________________
> Troy Dawson  [log in to unmask]  (630)840-6468
> Fermilab  ComputingDivision/CSS  CSI Group
> __________________________________________________
>

ATOM RSS1 RSS2