Re: dd of mounted filesystem
In the last episode (Dec 12), Dru said: > On Thu, 11 Dec 2003, Dan Nelson wrote: > > In the last episode (Dec 11), Matthew Seaman said: > > > Remember that dd(1) traverses the block device sequentially, but > > > that most FS accesses are random, so any particular change can > > > span either side of dd(1)'s offset. Also that dd'ing from the > > > block device bypasses the usual machinery for doing file IO -- > > > machinery that is designed under the premise that it will have > > > sole control over what gets read or written where and when. > > > > On current you can get around the consistency problem by dd'ing a > > snapshot of the filesystem, just like dump's -L flag does. > > You mean, run "makesnap_ffs" first? I've been meaning to play with > that one, I'll have to try it out. I don't think that's a standard FreeBSD command; what I was thinking of was something like: mount -u -o snapshot /usr/.snap/snap1 /usr dd if=/usr/.snap/snap1 of=blah bs=64k rm /usr/.snap/snap1 -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dd of mounted filesystem
On Thu, 11 Dec 2003, Dan Nelson wrote: > In the last episode (Dec 11), Matthew Seaman said: > > On Thu, Dec 11, 2003 at 02:54:12PM -0500, Dru wrote: > > > Can anyone describe or point me to resources explaining why it is > > > dangerous to dd a filesystem while it is mounted? Is it still > > > considered to be dangerous if the system is first dropped down to > > > single-user mode? > > > > Remember that dd(1) traverses the block device sequentially, but that > > most FS accesses are random, so any particular change can span either > > side of dd(1)'s offset. Also that dd'ing from the block device > > bypasses the usual machinery for doing file IO -- machinery that is > > designed under the premise that it will have sole control over what > > gets read or written where and when. > > On current you can get around the consistency problem by dd'ing a > snapshot of the filesystem, just like dump's -L flag does. You mean, run "makesnap_ffs" first? I've been meaning to play with that one, I'll have to try it out. Dru ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dd of mounted filesystem
- Original Message - From: "Dru" <[EMAIL PROTECTED]> Sent: Thursday, December 11, 2003 11:54 AM > Can anyone describe or point me to resources explaining why it is > dangerous to dd a filesystem while it is mounted? Is it still considered > to be dangerous if the system is first dropped down to single-user mode? I'm guessing between this thread and your "unmounting /" thread that you're attempting to duplicate your root drive? I just tried this in single user mode a few days ago with dd and it didn't work. The resulting file system was "dirty" so I used 'fsck' to clean it. The results were a complete unusable mess. I tried another method described in my thread "Trouble Adding New Boot Drive" but couldn't quite get it right. However I think I'm overlooking something quite simple. You might like to look over the steps I took and see if they make sense. Then if you get it to work, I'd be most appreciative if you'd let me know what I missed. I'll send the message to you if you want. Good Luck! Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dd of mounted filesystem
In the last episode (Dec 11), Matthew Seaman said: > On Thu, Dec 11, 2003 at 02:54:12PM -0500, Dru wrote: > > Can anyone describe or point me to resources explaining why it is > > dangerous to dd a filesystem while it is mounted? Is it still > > considered to be dangerous if the system is first dropped down to > > single-user mode? > > Remember that dd(1) traverses the block device sequentially, but that > most FS accesses are random, so any particular change can span either > side of dd(1)'s offset. Also that dd'ing from the block device > bypasses the usual machinery for doing file IO -- machinery that is > designed under the premise that it will have sole control over what > gets read or written where and when. On current you can get around the consistency problem by dd'ing a snapshot of the filesystem, just like dump's -L flag does. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dd of mounted filesystem
On Thu, Dec 11, 2003 at 02:54:12PM -0500, Dru wrote: > Can anyone describe or point me to resources explaining why it is > dangerous to dd a filesystem while it is mounted? Is it still considered > to be dangerous if the system is first dropped down to single-user mode? I assume you're talking about dd of the filesystem block devices, rather than anything else. dd'ing from a mounted filesystem is generally safe, although you won't get any sort of sensible result unless the source filesystem is inactive -- remounting the FS read-only should be sufficient. Using dd(1) to write to the block device of a mounted filesystem will at minimum create a horrible mess and at worst could well crash the machine. Remember that dd(1) traverses the block device sequentially, but that most FS accesses are random, so any particular change can span either side of dd(1)'s offset. Also that dd'ing from the block device bypasses the usual machinery for doing file IO -- machinery that is designed under the premise that it will have sole control over what gets read or written where and when. dd'ing to a mounted filesystem will overwrite the original inode structure, but the dd(1) process is going to be competing with the buffer cache, which will tend to write data back using it's cached version of the previous structure. You'll end up with a mess that fsck(1) probably couldn't sort out. Even if the target FS is mounted read-only the filesystem code will still probably throw a wobbly when it finds the disk contents have been changed out from underneath it. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 26 The Paddocks Savill Way PGP: http://www.infracaninophile.co.uk/pgpkey Marlow Tel: +44 1628 476614 Bucks., SL7 1TH UK pgp0.pgp Description: PGP signature
