Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Is the source directory quiescent? I've seen restore crash when the dump was taken of a rapidly changing filesystem. I'd expect some sort of diagnostics in that case, but you never know. Is this reproducible? Do you have any sense that the dump to file is progressing much faster than dump to pipe? Jerry Natowitz j.natowitz (at) rcn.com Edward Ned Harvey wrote: > This runs for a few minutes, and results in a broken pipe. After which, at > least some fragments of the filesystem have been restored on the destination > filesystem. At least some directories. > > cd /mnt/newFS > > dump -0af - /dev/someVG/sourceFS | restore -rf - > > > > This works fine. > > cd ~ > > dump -0af somefile /dev/someVG/sourceFS > > cd /mnt/newFS > > restore -rf ~/newFS > > > > Source and destination filesystems are ext3, 194G and 857G. Destination > filesystem is created with simply default mkfs.ext3. There are only approx. > 200M used in the source filesystem, of which, there's no particularly huge > directory or number of inodes or anything unusual... I forced the fsck, and > it came back clean. > > > > My only guess is that there seems to be something wrong with the pipe. > Like, it's not streaming the bits properly or something. Is it possible to > overflow a pipe or something? I can't think of any good explanation for > this weird behavior. What could cause a pipe to break, aside from the > receiving process terminating unexpectedly? > > _______________________________________________ > Discuss mailing list > Discuss-mNDKBlG2WHs at public.gmane.org > http://lists.blu.org/mailman/listinfo/discuss >
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |