cp: I do not understand ... - Aix

This is a discussion on cp: I do not understand ... - Aix ; Hi -- I have two identically-sized filesystems. The source is on an AIX 4.3 box; the target is on an AIX 5.3 box. Using NFS, I copy (cp -hpR) the source filesystem to the target. The copy eventually aborts because ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: cp: I do not understand ...

  1. cp: I do not understand ...

    Hi --

    I have two identically-sized filesystems. The source is on an AIX 4.3 box;
    the target is on an AIX 5.3 box.

    Using NFS, I copy (cp -hpR) the source filesystem to the target.

    The copy eventually aborts because the filesystem is full.

    The source filesystem is never even close to full (the largest one has been
    about 70% used).

    This has happened already with every filesystem I've created on the new
    server.

    What's going on? How can 5 GB of files on one machine overflow an 8 GB
    filesystem on another?

    Thanks,
    CL



  2. Re: cp: I do not understand ...

    Charles Lavin wrote:
    > Hi --
    >
    > I have two identically-sized filesystems. The source is on an AIX 4.3 box;
    > the target is on an AIX 5.3 box.
    >
    > Using NFS, I copy (cp -hpR) the source filesystem to the target.
    >
    > The copy eventually aborts because the filesystem is full.
    >
    > The source filesystem is never even close to full (the largest one has been
    > about 70% used).
    >
    > This has happened already with every filesystem I've created on the new
    > server.
    >
    > What's going on? How can 5 GB of files on one machine overflow an 8 GB
    > filesystem on another?
    >
    > Thanks,
    > CL
    >


    Are they identically sized or identically configured?
    Check settings for file systems on both machines.
    Does one machine have a much larger hard drive?

    I don't remember the exact AIX terminology but if you
    had the situation on a PC I would guess that you have
    many small files and the destination box has a larger
    clustersize.



  3. Re: cp: I do not understand ...

    On 2007-12-28, Charles Lavin wrote:

    > What's going on? How can 5 GB of files on one machine overflow an 8 GB
    > filesystem on another?


    This is actually quite easy

    # ulimit -f unlimited
    # df -m .
    Filesystem MB blocks Free %Used Iused %Iused Mounted on
    /dev/root_lv 32.00 30.89 4% 15 1% /root
    # dd if=/dev/zero of=testfile bs=4096 count=1 seek=131072000
    1+0 records in
    1+0 records out
    # ls -l testfile
    -rw-r--r-- 1 root system 536870916096 Dec 29 03:10 testfile
    # du -k testfile
    4 testfile
    #

    The dd command has generated a 500 gigabyte file called "testfile" in a
    filesystem that has only 20 megabytes free. As you can see from the output
    of the "ls" command, the file is indeed 500 gigabytes in size, but as you
    can see from the output of the "du" command, it only takes 4 kilobytes on
    disk.

    This is a so called "sparse file". This means that there's a "hole" in the
    file. A program (any program, not just "dd") can create a file with one or
    more "holes" in them. A program which opens such a file for reading, isn't
    aware of those holes. If it tries to read (part of) a hole, it reads
    zeros, just as if those zeros were written on the disk.

    What (most likely) happens in your case, is that "cp" opens the files for
    reading, and copies everything it reads to the new files in the new
    filesystem. If you have sparse files on the source filesystem, "cp" will
    read zeros from the hole, and will write those zeros to the new filesystem
    without creating any holes in the new filesystem. Look at what happens:

    # cp testfile testfile2
    cp: testfile2: No space left on device
    # ls -l testfile testfile2
    -rw-r--r-- 1 root system 536870916096 Dec 29 03:10 testfile
    -rw-r--r-- 1 root system 32382976 Dec 29 03:14 testfile2
    # df -m .
    Filesystem MB blocks Free %Used Iused %Iused Mounted on
    /dev/root_lv 32.00 0.00 100% 17 27% /root
    # du -k testfile*
    4 testfile
    31624 testfile2

    The "cp" command starts reading the source file (the 500 gigabyte file
    with a giant hole, so it only takes 4 kilobytes on disk), and starts
    writing the destination file. "cp" will read 500 gigabytes of zeros,
    and will try to write 500 gigabytes without creating holes. Because the
    filesystem is only 32 megabytes in size, this fails pretty quickly.

    Note that this behaviour differs across different UNIX flavours. Sparse files
    are pretty much the same everywhere, but on my OpenBSD box for example, "cp"
    *does* create sparse destination files.

    On AIX, the "restore" command will create sparse files when it detects large
    blocks of zeros in a file, so by using the "backup" and "restore" commands
    to copy your filesystems you'll most like succeed. I'm not sure (haven't
    got an AIX box available right now), but I *think* that when you use "backup"
    to create a backup by inode of an unmounted filesystem, it'll back up the
    files with knowledge of the holes, so "restore" can recreate them exactly as
    they were.


    --
    Jurjen Oskam

    Savage's Law of Expediency:
    You want it bad, you'll get it bad.

  4. Re: cp: I do not understand ...

    A df on each machine shows the exact number of total bytes (or blocks) on
    each filesystem.

    On the target machine, with the source filesystems mounted via NFS, a df
    shows the exact numbers of total bytes (blocks) on the local filesystem as
    on the remote one.

    But after the aborted copy, I get this:

    # df
    Filesystem 512-blocks Free %Used Iused %Iused Mounted on
    /dev/data1lv 8781824 0 100% 3718 97% /data1
    orion:/data1 8781824 1119368 88% 3885 1% /orion_data1

    And the full complement of files wasn't even copied over ...

    ???

    Tnx
    CL


    "sol gongola" wrote in message
    news:477547e2$0$13833$607ed4bc@cv.net...
    > Charles Lavin wrote:
    >> Hi --
    >>
    >> I have two identically-sized filesystems. The source is on an AIX 4.3
    >> box;
    >> the target is on an AIX 5.3 box.
    >>
    >> Using NFS, I copy (cp -hpR) the source filesystem to the target.
    >>
    >> The copy eventually aborts because the filesystem is full.
    >>
    >> The source filesystem is never even close to full (the largest one has
    >> been
    >> about 70% used).
    >>
    >> This has happened already with every filesystem I've created on the new
    >> server.
    >>
    >> What's going on? How can 5 GB of files on one machine overflow an 8 GB
    >> filesystem on another?
    >>
    >> Thanks,
    >> CL
    >>

    >
    > Are they identically sized or identically configured?
    > Check settings for file systems on both machines.
    > Does one machine have a much larger hard drive?
    >
    > I don't remember the exact AIX terminology but if you
    > had the situation on a PC I would guess that you have
    > many small files and the destination box has a larger
    > clustersize.
    >
    >




  5. Re: cp: I do not understand ...

    Hmmm ...

    I originally tried backup/restore. But there's not enough free space on any
    of the filesystems on the source server to make a copy of these filesystems.
    And when I tried to backup the remote system, AIX wouldn't let me (something
    about not supporting backing up to directories).

    I can't do this to/from tape. I'm 25 miles away from the tape drive.

    CL

    "Jurjen Oskam" wrote in message
    news:slrnfnakv7.600.jurjen@calvin.stupendous.org.. .
    > On 2007-12-28, Charles Lavin wrote:
    >
    >> What's going on? How can 5 GB of files on one machine overflow an 8 GB
    >> filesystem on another?

    >
    > This is actually quite easy
    >
    > # ulimit -f unlimited
    > # df -m .
    > Filesystem MB blocks Free %Used Iused %Iused Mounted on
    > /dev/root_lv 32.00 30.89 4% 15 1% /root
    > # dd if=/dev/zero of=testfile bs=4096 count=1 seek=131072000
    > 1+0 records in
    > 1+0 records out
    > # ls -l testfile
    > -rw-r--r-- 1 root system 536870916096 Dec 29 03:10 testfile
    > # du -k testfile
    > 4 testfile
    > #
    >
    > The dd command has generated a 500 gigabyte file called "testfile" in a
    > filesystem that has only 20 megabytes free. As you can see from the output
    > of the "ls" command, the file is indeed 500 gigabytes in size, but as you
    > can see from the output of the "du" command, it only takes 4 kilobytes on
    > disk.
    >
    > This is a so called "sparse file". This means that there's a "hole" in the
    > file. A program (any program, not just "dd") can create a file with one or
    > more "holes" in them. A program which opens such a file for reading, isn't
    > aware of those holes. If it tries to read (part of) a hole, it reads
    > zeros, just as if those zeros were written on the disk.
    >
    > What (most likely) happens in your case, is that "cp" opens the files for
    > reading, and copies everything it reads to the new files in the new
    > filesystem. If you have sparse files on the source filesystem, "cp" will
    > read zeros from the hole, and will write those zeros to the new filesystem
    > without creating any holes in the new filesystem. Look at what happens:
    >
    > # cp testfile testfile2
    > cp: testfile2: No space left on device
    > # ls -l testfile testfile2
    > -rw-r--r-- 1 root system 536870916096 Dec 29 03:10 testfile
    > -rw-r--r-- 1 root system 32382976 Dec 29 03:14 testfile2
    > # df -m .
    > Filesystem MB blocks Free %Used Iused %Iused Mounted on
    > /dev/root_lv 32.00 0.00 100% 17 27% /root
    > # du -k testfile*
    > 4 testfile
    > 31624 testfile2
    >
    > The "cp" command starts reading the source file (the 500 gigabyte file
    > with a giant hole, so it only takes 4 kilobytes on disk), and starts
    > writing the destination file. "cp" will read 500 gigabytes of zeros,
    > and will try to write 500 gigabytes without creating holes. Because the
    > filesystem is only 32 megabytes in size, this fails pretty quickly.
    >
    > Note that this behaviour differs across different UNIX flavours. Sparse
    > files
    > are pretty much the same everywhere, but on my OpenBSD box for example,
    > "cp"
    > *does* create sparse destination files.
    >
    > On AIX, the "restore" command will create sparse files when it detects
    > large
    > blocks of zeros in a file, so by using the "backup" and "restore" commands
    > to copy your filesystems you'll most like succeed. I'm not sure (haven't
    > got an AIX box available right now), but I *think* that when you use
    > "backup"
    > to create a backup by inode of an unmounted filesystem, it'll back up the
    > files with knowledge of the holes, so "restore" can recreate them exactly
    > as
    > they were.
    >
    >
    > --
    > Jurjen Oskam
    >
    > Savage's Law of Expediency:
    > You want it bad, you'll get it bad.




  6. Re: cp: I do not understand ...

    On 2007-12-28, Charles Lavin wrote:

    [copying (most likely) sparse files fails]
    > I originally tried backup/restore.


    Yes, but did you try using backup/restore with the source filesystem
    *unmounted*?

    You could (as an alternative) try to find the sparse files on the source
    filesystem. Look for (very) large files, and then use "du" to see how much
    space they take on disk. Or try to script something. If there are maybe one or
    two files causing your problems, you might be able to just recreate them
    on the new filesystem instead of copying them over.

    --
    Jurjen Oskam

    Savage's Law of Expediency:
    You want it bad, you'll get it bad.

  7. Re: cp: I do not understand ...

    We copied all the filesystems over with rcp, and the problem went away.


    "Jurjen Oskam" wrote in message
    news:slrnfnap4c.vgu.jurjen@calvin.stupendous.org.. .
    > On 2007-12-28, Charles Lavin wrote:
    >
    > [copying (most likely) sparse files fails]
    >> I originally tried backup/restore.

    >
    > Yes, but did you try using backup/restore with the source filesystem
    > *unmounted*?
    >
    > You could (as an alternative) try to find the sparse files on the source
    > filesystem. Look for (very) large files, and then use "du" to see how much
    > space they take on disk. Or try to script something. If there are maybe
    > one or
    > two files causing your problems, you might be able to just recreate them
    > on the new filesystem instead of copying them over.
    >
    > --
    > Jurjen Oskam
    >
    > Savage's Law of Expediency:
    > You want it bad, you'll get it bad.




+ Reply to Thread