Doug, I don't have any recent experience (<2yr old) with dump, but when I last used it in late 1999, I had very bad problems with ext2 and any filesystem larger than about 4G, and ended up abandoning it, which was too bad, as I really liked the dump & restore interface. The error I saw is the bread error you're seeing. I've heard gnu tar supports many of the features (e.g. incremental backups) that I wanted, but I haven't tried it.
David On Thu, 12 Dec 2002, Doug Mildram wrote: > I got a californiadigital.com (was VAlinux) box, with 3ware controllers > (takes IDE drives, appears as SCSI with HW-raid on the controller). > > Price/performance looks great; > Under $15K for 2tb (2 controllers, 8x160gb on each). > Redhat7.3 installs with no extra drivers > (it only sees one BIG disk per scsi controller. Too big for dump, maybe.) > Have tried googling for this bug, but only vague and old problems/reports > about 32-bit lseek versus 64bit (which is a likely suspect.) ANYWAYS: > > QUESTION: HOW MANY OF YOU FOLKS have BIG linux ext3 filesystems, > and have you tried "dump" to back them up? > > -------details: > > MY BUG: I want to use "dump", sparingly at least, for tape archiving. > I supposed I could abandon it and use "tar" or something else. > > Don't need/want to backup ENTIRE 1tb, > but linux "dump" supports subdir level0 dumping, which sounds good. > > But, dump spits out errors, I've only put 30gb (3%) on a healthy > filesystem, but I think the size or #inodes is too much for dump, which > spits out (60,000 times on a dump/fsys of 180,000 files, I notice > that the inode numbers jump quickly upwards; > mine range from 11...to 32k...to 64k...to 96k...and so on up to 138625035) > (1:lost+found),,,(12 files),(18),,(14).....in chunks, that is.) > > THE ERROR: DUMP: bread: lseek fails (seeing this line 60,000 times) > > This occurs seemingly dependent on what files are backed up > more than on the total size of the dump. > > Actually, it's not a FATAL error to dump, which finishes anyways > with happy return status. > > My old-BSD experience taught me that "bread" means "block-read", > which used to imply a nasty disk error. But, I can "dd" the entire > disk without errors (which takes 2-3 hours on a 1tb-fsys.) > > I've tried to tape (a 30gb-chunk of data would fit on the DLT7000), > got the same errors AT THE END (after 97% with no errors, it > explodes with the 60,000 errors.) > > Same result dumping to disk using a command like: > > /sbin/rdump 0bBMf 63 1048576 /otherfsys/tmpdir/prefix /bigfsys > > (the M flag allows multi-volume dumpfiles in the tmpdir, > the 1048576 means limit each vol/dumpfile to 1gb.) > > Thanks for listening..... sorry I couldnt make it into cambridge yesterday. > ================================================================ > Doug Mildram Mindspeed Technologies > [EMAIL PROTECTED] 8 Technology Drive > Systems Admin. Westborough, MA 01581 > > > --- > Send mail for the `bblisa' mailing list to `[EMAIL PROTECTED]'. > Mail administrative requests to `[EMAIL PROTECTED]'. > --- Send mail for the `bblisa' mailing list to `[EMAIL PROTECTED]'. Mail administrative requests to `[EMAIL PROTECTED]'.
