xfsdump Problems - SGI

This is a discussion on xfsdump Problems - SGI ; Hello All, I'm having problems with a level 0 dump of a filesystem via xfsdump. Here's the dump environment: IRIX 6.5.20m (with full patches without support) on Indy R5000. Python 01931-XXX5.63 DDS2 DAT drive. Two brand new Sony DGD120P DDS2 ...

+ Reply to Thread
Results 1 to 14 of 14

Thread: xfsdump Problems

  1. xfsdump Problems


    Hello All,

    I'm having problems with a level 0 dump of a filesystem via xfsdump.
    Here's the dump environment:

    IRIX 6.5.20m (with full patches without support) on Indy R5000.
    Python 01931-XXX5.63 DDS2 DAT drive.
    Two brand new Sony DGD120P DDS2 tapes.

    The dump source is about 5.45 Gbytes in size and spans two tapes
    requiring me to swap tapes during the dump session.
    This is the dump summary I'm seeing at about 98/99% the way through
    the dump session (after I've swapped to tape #2):

    xfsdump: Dump Summary:
    xfsdump: stream 0 (pid 1913) /dev/rmt/tps0d5c NONE (no error code)
    xfsdump: stream 0 (pid 1912) /dev/rmt/tps0d5c CORRUPTION (corrupt data
    encountered)
    xfsdump: Dump Status: INCOMPLETE

    I also see the same thing when using the /dev/tape device.

    The dump source is a bootable IRIX6.2 system disk.
    Searching through those parts of support.sgi.com that I can get to
    without a support contract does not reveal any xfsdump bug reports
    that might address the above. Nor does searching groups.google.com.
    My SCSI bus is terminated and I'm using known good cabling.

    Any thoughts on the above would be appreciated.

    Thanks,

    Josh.

    ..------------------------------------------------.
    | Josh Birnbaum Mail: engineer@noorg.org |
    | President Internet: www.noorg.org |
    | Noorg, Inc |
    | ---------------------------------------------- |
    | ifchk - host based promiscuous mode detection |
    | & handling available for download at: |
    | http://www.noorg.org/ifchk/ |
    `------------------------------------------------'

  2. Re: xfsdump Problems

    In comp.sys.sgi.admin noorg wrote:
    >
    > Hello All,
    >
    > I'm having problems with a level 0 dump of a filesystem via xfsdump.
    > Here's the dump environment:


    Hey josh,

    email keeps bouncing. drop me a line i can probably help you with this
    issue.

    cheers.

  3. Re: xfsdump Problems

    noorg writes:
    > xfsdump: Dump Summary:
    > xfsdump: stream 0 (pid 1913) /dev/rmt/tps0d5c NONE (no error code)
    > xfsdump: stream 0 (pid 1912) /dev/rmt/tps0d5c CORRUPTION (corrupt data
    > encountered)
    > xfsdump: Dump Status: INCOMPLETE


    I have not encountered the above error myself, but it might be because
    of

    a) an error in the filesystem in question. Have you tried running
    xfs_repair on the filesystem?

    b) xfsdump keeps logs of the backups it produces. You could face
    problems if these are damaged somehow. You might want to look into
    /var/xfsdump/inventory.

    a) seems more probable than b) to me. I'm unaware of how much temporary
    disk space (if any) xfsdump needs, but you could also have run out of
    space in /tmp or /usr/tmp.

    Thomas Jahns
    --
    "Computers are good at following instructions,
    but not at reading your mind."
    D. E. Knuth, The TeXbook, Addison-Wesley 1984, 1986, 1996, p. 9

  4. Re: xfsdump Problems

    Hi Thomas,

    > I have not encountered the above error myself, but it might be because
    > of
    >
    > a) an error in the filesystem in question. Have you tried running
    > xfs_repair on the filesystem?


    xfs_check and xfs_repair did not reveal any problems.
    However, I still got the "CORRUPTION" and "INCOMPLETE" messages after
    performing the xfs_check and xfs_repair.

    This 5.45 Gbyte dump image is the only thing I've been working with.
    I'm going to try to dump something small (eg. 20 or so Mbytes in
    size) just to see what I get.

    Another thing that's crossed my mind is the possiblilty of a bug in
    xfs_dump.

    > b) xfsdump keeps logs of the backups it produces. You could face
    > problems if these are damaged somehow. You might want to look into
    > /var/xfsdump/inventory.


    Hmm. I'll look into this.
    Though I should say that I saw the CORRUPTION/INCOMPLETE xfs_dump dump
    status after the very _first_ xfs_dump session ever to take place under
    the IRIX 6.5 image I was running. Prior to this dump session, the
    /var/xfsdump/inventory directory never had _any_ logs in it.

    > a) seems more probable than b) to me. I'm unaware of how much temporary
    > disk space (if any) xfsdump needs, but you could also have run out of
    > space in /tmp or /usr/tmp.


    /dev/dsk/dks0d1s0 is a 9 Gbyte volume partitioned root only with the
    only addition being the default 128 Mbyte swap partition created during
    the fx session prior to base IRIX installation.
    /tmp and /usr/tmp are indeed on /dev/dsk/dks0d1s0 which is mounted at
    the default /dev/root.

    Another thought. I wonder if io_ring_length was too small. I was
    using the default 3 by 2MB ring. I'll search groups.google.com for
    this to see if this is pertinant.

    Also, I forgot to include the xfs_dump command line I used. Here it
    is:

    xfsdump -f /dev/tape -l 0 -L iris08062004 -M tape00 -p 120 -v verbose
    /CDROM

    Thomas, thanks for your reply to my question.

    Yours,

    Josh.

    ..------------------------------------------------.
    | Josh Birnbaum Mail: engineer@noorg.org |
    | President Internet: www.noorg.org |
    | Noorg, Inc |
    | ---------------------------------------------- |
    | ifchk - host based promiscuous mode detection |
    | & handling available for download at: |
    | http://www.noorg.org/ifchk/ |
    `------------------------------------------------'

  5. Re: xfsdump Problems

    In comp.sys.sgi.hardware noorg wrote:

    > Hello All,


    > I'm having problems with a level 0 dump of a filesystem via xfsdump.
    > Here's the dump environment:


    > IRIX 6.5.20m (with full patches without support) on Indy R5000.
    > Python 01931-XXX5.63 DDS2 DAT drive.
    > Two brand new Sony DGD120P DDS2 tapes.


    > The dump source is about 5.45 Gbytes in size and spans two tapes
    > requiring me to swap tapes during the dump session.
    > This is the dump summary I'm seeing at about 98/99% the way through
    > the dump session (after I've swapped to tape #2):

    [.....]

    Seems the problem is either caused by the DAT drive or by the SCSI controller
    of the Indy. I cloned my system disk some days ago (Octane) with
    xfsdump/ xfsrestore and it did perfectly; data to copy was about 40GB
    (it took some time but showed no error), system is 6.5.23f. I did a
    similar clonig some months ago with less data (10~20GB) and 6.5.20f and
    did not see any trobles. Did you verify the tapes are OK?

    Toni
    (fup2cssm)

  6. Re: xfsdump Problems


    Hi Toni,

    > Seems the problem is either caused by the DAT drive or by the
    > SCSI controller of the Indy.


    It's too early to tell. Though, to that end, I'm not seeing any-
    thing in /var/adm/SYSLOG that would suggest this. Nor am I getting
    SCSI bus resets, etc.
    The next thing to try is a smaller dump from a different source
    to see if xfs_dump completes without error.

    > I cloned my system disk some days ago (Octane) with
    > xfsdump/ xfsrestore and it did perfectly; data to copy was about 40GB
    > (it took some time but showed no error), system is 6.5.23f. I did a
    > similar clonig some months ago with less data (10~20GB) and 6.5.20f and
    > did not see any trobles.


    Yeah, this is the best way to clone XFS filesystems.

    > Did you verify the tapes are OK?


    Yes, the media was just purchased brand new and shrink wrapped.
    And, the DAT drive got a cleaning with a DDS cleaning cartridge
    prior to the dump sessions.

    > Toni
    > (fup2cssm)


    Yours,

    Josh.

    ..------------------------------------------------.
    | Josh Birnbaum Mail: engineer@noorg.org |
    | President Internet: www.noorg.org |
    | Noorg, Inc |
    | ---------------------------------------------- |
    | ifchk - host based promiscuous mode detection |
    | & handling available for download at: |
    | http://www.noorg.org/ifchk/ |
    `------------------------------------------------'

  7. Re: xfsdump Problems

    noorg writes:
    [xfs_repair reports no errors, /var/lib/xfsdump new, probably no tmp
    problem]

    Another thought that crossed my mind is this: xfsdump might fail if the
    tape drive capabilities are entered incorrectly in
    /var/sysgen/master.d/scsi? You have put an entry there, haven't you?

    If so could you post your entry, it would correspond to the following
    entry for an HP 1533 drive:

    { DATTAPE, TPDAT, 2, 6, "HP", "C1533A", 0, 0, {0, 0, 0, 0},
    MTCAN_BSF|MTCAN_BSR|MTCAN_APPEND|MTCAN_SETMK|MTCAN _PART|MTCAN_PREV|
    MTCAN_SYNC|MTCAN_SPEOD|MTCAN_CHKRDY|MTCAN_VAR|MTCA N_SETSZ|
    MTCAN_SILI|MTCAN_SEEK|MTCAN_CHTYPEANY,
    /* minimum delay on i/o is 4 minutes, because when a retry is
    * performed, the drive retries a number of times, and then
    * rewinds to BOT, repositions, and tries again. */
    40, 4*60, 4*60, 5*60, 512, 512*512 },

    and how is your tape drive reported in hinv?


    Thomas Jahns
    --
    "Computers are good at following instructions,
    but not at reading your mind."
    D. E. Knuth, The TeXbook, Addison-Wesley 1984, 1986, 1996, p. 9

  8. Re: xfsdump Problems

    Hi Thomas,

    > noorg writes:
    > [xfs_repair reports no errors, /var/lib/xfsdump new, probably no tmp
    > problem]
    >
    > Another thought that crossed my mind is this: xfsdump might fail if the
    > tape drive capabilities are entered incorrectly in
    > /var/sysgen/master.d/scsi? You have put an entry there, haven't you?
    >
    > If so could you post your entry, it would correspond to the following
    > entry for an HP 1533 drive:
    >
    > { DATTAPE, TPDAT, 2, 6, "HP", "C1533A", 0, 0, {0, 0, 0, 0},
    > MTCAN_BSF|MTCAN_BSR|MTCAN_APPEND|MTCAN_SETMK|MTCAN _PART|MTCAN_PREV|
    > MTCAN_SYNC|MTCAN_SPEOD|MTCAN_CHKRDY|MTCAN_VAR|MTCA N_SETSZ|
    > MTCAN_SILI|MTCAN_SEEK|MTCAN_CHTYPEANY,
    > /* minimum delay on i/o is 4 minutes, because when a retry is
    > * performed, the drive retries a number of times, and then
    > * rewinds to BOT, repositions, and tries again. */
    > 40, 4*60, 4*60, 5*60, 512, 512*512 },


    Here is the /var/sysgen/master.d/scsi entry:

    { DATTAPE, TPDAT, 7, 12, "ARCHIVE", "Python 01931" /*DDS2*/, 0, 0, {0},
    /* note: this drive uses modeselect page 0xf for compression
    control;
    * most of the other drives supporting compression use page 0x10 */
    MTCAN_BSF|MTCAN_BSR|MTCAN_APPEND|MTCAN_SETMK|MTCAN _PART|MTCAN_PREV|
    MTCAN_SYNC|MTCAN_SPEOD|MTCAN_CHKRDY|MTCAN_VAR|MTCA N_SETSZ|
    MTCAN_SILI|MTCAN_AUDIO|MTCAN_SEEK|MTCAN_CHTYPEANY| MTCAN_COMPRESS,
    /* minimum delay on i/o is 4 minutes, because when a retry is
    * performed, the drive retries a number of times, and then
    * rewinds to BOT, repositions, and tries again. */
    40, 4*60, 4*60, 5*60, 3*3600, 512, 512*512,
    tpsc_default_dens_count, tpsc_default_hwg_dens_names,
    tpsc_default_alias_dens_names,
    {0}, 0, 0, 0,
    0, (u_char *)0 },



    > and how is your tape drive reported in hinv?


    Tape drive: unit 5 on SCSI controller 0: DAT

    `mt status` reports:

    Device: ARCHIVE: Python 01931-XXX5.63

    Thanks,

    Josh.

    > Thomas Jahns
    > --
    > "Computers are good at following instructions,
    > but not at reading your mind."
    > D. E. Knuth, The TeXbook, Addison-Wesley 1984, 1986, 1996, p. 9


    --

    ..------------------------------------------------.
    | Josh Birnbaum Mail: engineer@noorg.org |
    | President Internet: www.noorg.org |
    | Noorg, Inc |
    | ---------------------------------------------- |
    | ifchk - host based promiscuous mode detection |
    | & handling available for download at: |
    | http://www.noorg.org/ifchk/ |
    `------------------------------------------------'

  9. Re: xfsdump Problems

    Hi Folks,

    I've just finished a level 0 dump of a 6.5.20 system disk
    under IRIX 6.2 using the 6.2 xfsdump implementation where-
    as IRIX 6.5.20 xfsdump has been failing (as documented in
    earlier posts of this thread). This xfsdump implementation
    is part of patchSG0003289.eoe_sw.xfs for IRIX6.2.

    Are there known problems with xfsdump as supplied by IRIX
    6.5.20? I'm going to check support.sgi.com again as well.
    Any thoughts?

    Thanks,

    Josh.

    ..------------------------------------------------.
    | Josh Birnbaum Mail: engineer@noorg.org |
    | President Internet: www.noorg.org |
    | Noorg, Inc |
    | ---------------------------------------------- |
    | ifchk - host based promiscuous mode detection |
    | & handling available for download at: |
    | http://www.noorg.org/ifchk/ |
    `------------------------------------------------'

  10. Re: xfsdump Problems

    noorg writes:
    [tape drive properly configured]

    Sorry, but I have run out of ideas for the moment.
    Any other tape users here that could provide some input?

    Thomas Jahns
    --
    "Computers are good at following instructions,
    but not at reading your mind."
    D. E. Knuth, The TeXbook, Addison-Wesley 1984, 1986, 1996, p. 9

  11. Re: xfsdump Problems

    noorg wrote:
    >

    [snip]

    >
    > /dev/dsk/dks0d1s0 is a 9 Gbyte volume partitioned root only with the
    > only addition being the default 128 Mbyte swap partition created during
    > the fx session prior to base IRIX installation.
    > /tmp and /usr/tmp are indeed on /dev/dsk/dks0d1s0 which is mounted at
    > the default /dev/root.
    >
    > Another thought. I wonder if io_ring_length was too small. I was
    > using the default 3 by 2MB ring. I'll search groups.google.com for
    > this to see if this is pertinant.


    I wouldn't have thought that would be a problem. The defaults have
    always worked fine for me with various DAT drives.

    >
    > Also, I forgot to include the xfs_dump command line I used. Here it
    > is:
    >
    > xfsdump -f /dev/tape -l 0 -L iris08062004 -M tape00 -p 120 -v verbose
    > /CDROM
    >


    Are you trying to dump the CDROM? That would seem a bit strange.

    Have you tried doing an xfsdump to disk rather than tape? Can you work
    the tape happily with tar or dd? Have you tried using the
    non-compression device instead?

    You say the error occurs after you have swapped tapes. What if you do a
    smaller dump which only needs one tape? Does that cause errors?

    I use xfsdump across multiple tapes and drives without troubles from my
    Octane. One of my DAT drives is the same model as yours. The only
    troubles I have encountered have been when I used the non-rewinding
    devices, and then switched the machine off with the tape not rewound.
    That seems to corrupt the tape at the point it was up to. I'm still
    running IRIX 6.5.15, mind you, so it is always possible there are some
    extra bugs in 6.5.20.

    You could pick up another DDS2 or DDS3 drive from ebay for 20 or 30 GBP.

    --
    Dr Tristram J. Scott
    Energy Consultant

  12. Re: xfsdump Problems

    In article <41194CEB.ABB578C6@noorg.org>, noorg wrote:
    :Another thought. I wonder if io_ring_length was too small. I was
    :using the default 3 by 2MB ring. I'll search groups.google.com for
    :this to see if this is pertinant.

    Some time ago, I had SGI build a one-off copy of xfsdump so that
    I could test larger ring sizes. With the equipment we had at the
    time, the peak transfer rates were at -Y 2 (sometimes), -Y 3 (most
    of the time), or -Y 4 (sometimes). I went up to -Y 10 and never saw
    a more-than-marginal speed increase, and in my tests there was no
    dump upon which there was any benefit in going past -Y 6 -- and
    the difference between -Y 5 and -Y 6 were within the margin of
    error of measurement.

    In other words, there was never any point in going beyond -Y 4,
    at least with that generation of equipment, and the differences
    between -Y 3 and -Y 4 were barely worth considering. Reducing down
    to -Y 2 was better often enough to be worth considering on some
    systems!


    It might be interesting to revisit this test on a system which
    had been highly tuned for disk and tape I/O, but I don't have such
    a system, and I doubt I still have that copy of xfsdump (which
    certainly wasn't compiled with the latest compilers and using the
    latest features, etc.)
    --
    We don't need no side effect-ing
    We don't need no scope control
    No global variables for execution
    Hey! Did you leave those args alone? -- decvax!utzoo!utcsrgv!roderick

  13. Re: xfsdump Problems

    Hi Tristram,

    > > Another thought. I wonder if io_ring_length was too small. I was
    > > using the default 3 by 2MB ring. I'll search groups.google.com for
    > > this to see if this is pertinant.

    >
    > I wouldn't have thought that would be a problem. The defaults have
    > always worked fine for me with various DAT drives.


    Thanks for that confirmation.

    > >
    > > Also, I forgot to include the xfs_dump command line I used. Here it
    > > is:
    > >
    > > xfsdump -f /dev/tape -l 0 -L iris08062004 -M tape00 -p 120 -v verbose
    > > /CDROM
    > >

    >
    > Are you trying to dump the CDROM? That would seem a bit strange.


    No. /CDROM is just a mount point for the dump source which is an
    IRIX system disk (IRIX6.5.20 boot volume).

    > Have you tried doing an xfsdump to disk rather than tape?


    Not yet.

    > Can you work the tape happily with tar or dd?


    I've not tried but I should give this a whirl.

    > Have you tried using the non-compression device instead?


    I'm using the default /dev/tape device.

    > You say the error occurs after you have swapped tapes. What if you do a
    > smaller dump which only needs one tape? Does that cause errors?


    I recently finished a level 0 dump of a 6.5.20 system disk under IRIX
    6.2
    using the 6.2 xfsdump implementation whereas IRIX 6.5.20 xfsdump has
    been
    failing (as documented in earlier posts of this thread). This xfsdump
    implementation is part of patchSG0003289.eoe_sw.xfs for IRIX6.2.
    The dump target was a single tape.

    Given the above, I think I may have encountered an xfsdump bug. I need
    to
    firm up that hypothesis though.

    > I use xfsdump across multiple tapes and drives without troubles from my
    > Octane. One of my DAT drives is the same model as yours. The only
    > troubles I have encountered have been when I used the non-rewinding
    > devices, and then switched the machine off with the tape not rewound.
    > That seems to corrupt the tape at the point it was up to. I'm still
    > running IRIX 6.5.15, mind you, so it is always possible there are some
    > extra bugs in 6.5.20.


    I've never had problems with this DAT drive.

    > You could pick up another DDS2 or DDS3 drive from ebay for 20 or 30 GBP.


    I'm not convinced that it's a DAT drive problem.

    Thanks for your response.

    > --
    > Dr Tristram J. Scott
    > Energy Consultant


    Yours,

    Josh.

    ..------------------------------------------------.
    | Josh Birnbaum Mail: engineer@noorg.org |
    | President Internet: www.noorg.org |
    | Noorg, Inc |
    | ---------------------------------------------- |
    | ifchk - host based promiscuous mode detection |
    | & handling available for download at: |
    | http://www.noorg.org/ifchk/ |
    `------------------------------------------------'

  14. Re: xfsdump Problems

    look for sash


    noorg wrote:

    > Hello All,
    >
    > I'm having problems with a level 0 dump of a filesystem via xfsdump.
    > Here's the dump environment:
    >
    > IRIX 6.5.20m (with full patches without support) on Indy R5000.
    > Python 01931-XXX5.63 DDS2 DAT drive.
    > Two brand new Sony DGD120P DDS2 tapes.
    >
    > The dump source is about 5.45 Gbytes in size and spans two tapes
    > requiring me to swap tapes during the dump session.
    > This is the dump summary I'm seeing at about 98/99% the way through
    > the dump session (after I've swapped to tape #2):
    >
    > xfsdump: Dump Summary:
    > xfsdump: stream 0 (pid 1913) /dev/rmt/tps0d5c NONE (no error code)
    > xfsdump: stream 0 (pid 1912) /dev/rmt/tps0d5c CORRUPTION (corrupt data
    > encountered)
    > xfsdump: Dump Status: INCOMPLETE
    >
    > I also see the same thing when using the /dev/tape device.
    >
    > The dump source is a bootable IRIX6.2 system disk.
    > Searching through those parts of support.sgi.com that I can get to
    > without a support contract does not reveal any xfsdump bug reports
    > that might address the above. Nor does searching groups.google.com.
    > My SCSI bus is terminated and I'm using known good cabling.
    >
    > Any thoughts on the above would be appreciated.
    >
    > Thanks,
    >
    > Josh.
    >
    > .------------------------------------------------.
    > | Josh Birnbaum Mail: engineer@noorg.org |
    > | President Internet: www.noorg.org |
    > | Noorg, Inc |
    > | ---------------------------------------------- |
    > | ifchk - host based promiscuous mode detection |
    > | & handling available for download at: |
    > | http://www.noorg.org/ifchk/ |
    > `------------------------------------------------'
    >



+ Reply to Thread