Block device to regular file?
I'm trying to recover some deleted files from a UFS2 file system with the sleuthkit. Unfortunatly, most sleuthkit utilities expect regular image files and won't operate on block devices: phenom# fls /dev/ad4s1e Sector offset supplied is larger than disk image (maximum: 0) Of course, I could always dd(1) the block device into another file system, and analyze that: phenom# dd if=/dev/ad4s1e of=/mnt/ad4s1e.dd phenom# fls /mnt/ad4s1e.dd | more regular-output-of-fls but unfortunatly, the file system I'm trying to analyze is VERY large and I don't have enough disk space elsewhere to take an image. Now, is there an easy way to turn a block device into something that would behave like a regular file? Something like mdconfig -t vnode, but in reverse? Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Block device to regular file?
On Tue, 14 Apr 2009 18:17:24 +0200, cpghost cpgh...@cordula.ws wrote: I'm trying to recover some deleted files from a UFS2 file system with the sleuthkit. :-( Unfortunatly, most sleuthkit utilities expect regular image files and won't operate on block devices: phenom# fls /dev/ad4s1e Sector offset supplied is larger than disk image (maximum: 0) Because I already have my own sad story of data loss, I could provide the idea of using FreeBSD's memory disks. I've always used this to get TSK tools working the other way round, when I had a dd copy, but required a device file. Maybe this works as well in your case when you create a virtual note for the device file: # mdconfig -a -t vnode -u 10 -f /dev/ad4s1e md10 You can now use TSK with /dev/md10, but I can't confirm that it won't complain. Of course, I could always dd(1) the block device into another file system, and analyze that: phenom# dd if=/dev/ad4s1e of=/mnt/ad4s1e.dd phenom# fls /mnt/ad4s1e.dd | more regular-output-of-fls but unfortunatly, the file system I'm trying to analyze is VERY large and I don't have enough disk space elsewhere to take an image. I would strongly advice you *not* to experiment with the original disk, because this *may* lead you to more problems. Hard disks are cheap today. Buy a fresh disk and make a dd copy onto it. Work with this dd copy only - if the dd copy is a real copy (and therefore replicates the defects of the original file system). In my case, I'm talking about a ca. 80 GB partition which needs 4 hours to be transferred. Always have in mind that your data may be more important than the money for a new disk and the time spent for the dd copy. Now, is there an easy way to turn a block device into something that would behave like a regular file? Something like mdconfig -t vnode, but in reverse? Maybe you could dd the partition into a (named) pipe and then run TSK on this pipe? Anyway, I'm not sure if this is such a good idea... -- Polytropon From Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Block device to regular file?
On Tue, Apr 14, 2009 at 07:18:43PM +0200, Polytropon wrote: On Tue, 14 Apr 2009 18:17:24 +0200, cpghost cpgh...@cordula.ws wrote: I'm trying to recover some deleted files from a UFS2 file system with the sleuthkit. Unfortunatly, most sleuthkit utilities expect regular image files and won't operate on block devices: phenom# fls /dev/ad4s1e Sector offset supplied is larger than disk image (maximum: 0) Because I already have my own sad story of data loss, I could provide the idea of using FreeBSD's memory disks. I've always used this to get TSK tools working the other way round, when I had a dd copy, but required a device file. Maybe this works as well in your case when you create a virtual note for the device file: # mdconfig -a -t vnode -u 10 -f /dev/ad4s1e md10 You can now use TSK with /dev/md10, but I can't confirm that it won't complain. Hmmm, I'm getting this: phenom# mdconfig -a -t vnode -o readonly -f /dev/ad4s1e mdconfig: ioctl(/dev/mdctl): Invalid argument phenom# mdconfig -a -t vnode -f /dev/ad4s1e mdconfig: ioctl(/dev/mdctl): Invalid argument So, it doesn't seem to work. But it was a good idea. Probably block devices aren't mappable like regular files. Of course, I could always dd(1) the block device into another file system, and analyze that: phenom# dd if=/dev/ad4s1e of=/mnt/ad4s1e.dd phenom# fls /mnt/ad4s1e.dd | more regular-output-of-fls but unfortunatly, the file system I'm trying to analyze is VERY large and I don't have enough disk space elsewhere to take an image. I would strongly advice you *not* to experiment with the original disk, because this *may* lead you to more problems. Hard disks are cheap today. Buy a fresh disk and make a dd copy onto it. Work with this dd copy only - if the dd copy is a real copy (and therefore replicates the defects of the original file system). If at all, the block device would have to be used in read-only mode. But that's not the issue here. The file system itself is over 470GB (it occuples the whole 500GB disk), and while I do have spare 500GB disks, the whole image won't fit into a filesystem: it will be slightly too big. Bigger disks won't work on that mobo without a bios upgrade, which is not yet available for that machine. I'll probably try to dd(1) the disk with conv=sparse, hoping that it will compress enough to fit, but I was hoping to find a FUSE daemon or something like that, that would turn a block device into a regular file (preferably in read-only mode). In my case, I'm talking about a ca. 80 GB partition which needs 4 hours to be transferred. Yup, 80 GB are still manageable enough. The disk I have to recover was set up by someone who didn't have a clue in sensible filesystem layout. :-( Always have in mind that your data may be more important than the money for a new disk and the time spent for the dd copy. Of course. Now, is there an easy way to turn a block device into something that would behave like a regular file? Something like mdconfig -t vnode, but in reverse? Maybe you could dd the partition into a (named) pipe and then run TSK on this pipe? Nope. Apparently, TSK tools also seek back, so... :( Anyway, I'm not sure if this is such a good idea... Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Block device to regular file?
On Tue, Apr 14, 2009 at 07:48:16PM +0200, cpghost wrote: On Tue, Apr 14, 2009 at 07:18:43PM +0200, Polytropon wrote: On Tue, 14 Apr 2009 18:17:24 +0200, cpghost cpgh...@cordula.ws wrote: I'm trying to recover some deleted files from a UFS2 file system with the sleuthkit. Unfortunatly, most sleuthkit utilities expect regular image files and won't operate on block devices: For the record, FreeBSD doesn't have block devices. They are all character devices. Compare the output of ls -l /dev | grep '^b' with that of ls -l /dev | grep '^c'. Might this be what is bugging sleuthkit? phenom# mdconfig -a -t vnode -o readonly -f /dev/ad4s1e mdconfig: ioctl(/dev/mdctl): Invalid argument The vnode type md can only use regular files. See md(4). but unfortunatly, the file system I'm trying to analyze is VERY large and I don't have enough disk space elsewhere to take an image. Well, fls and other sleuthkit programs support split images. Will it fit if you divide it into several smaller files? I would strongly advice you *not* to experiment with the original disk, because this *may* lead you to more problems. very good advice IMHO. But that's not the issue here. The file system itself is over 470GB (it occuples the whole 500GB disk), and while I do have spare 500GB disks, the whole image won't fit into a filesystem: it will be slightly too big. Maybe it will fit if you play with the newfs parameters of the new disk? Shrinking the reserved space, enlarging the block and fragment size and reducing the number of inodes, that kind of thing. Roland -- R.F.Smith http://www.xs4all.nl/~rsmith/ [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) pgpoZBSyxmqHH.pgp Description: PGP signature
Re: Block device to regular file?
On Tue, Apr 14, 2009 at 09:36:22PM +0200, Roland Smith wrote: On Tue, Apr 14, 2009 at 07:48:16PM +0200, cpghost wrote: On Tue, Apr 14, 2009 at 07:18:43PM +0200, Polytropon wrote: On Tue, 14 Apr 2009 18:17:24 +0200, cpghost cpgh...@cordula.ws wrote: I'm trying to recover some deleted files from a UFS2 file system with the sleuthkit. Unfortunatly, most sleuthkit utilities expect regular image files and won't operate on block devices: For the record, FreeBSD doesn't have block devices. They are all character devices. Compare the output of ls -l /dev | grep '^b' with that of ls -l /dev | grep '^c'. Ups, right. My mistake. Might this be what is bugging sleuthkit? They try to get the file size of the char device... phenom# mdconfig -a -t vnode -o readonly -f /dev/ad4s1e mdconfig: ioctl(/dev/mdctl): Invalid argument The vnode type md can only use regular files. See md(4). Yep. but unfortunatly, the file system I'm trying to analyze is VERY large and I don't have enough disk space elsewhere to take an image. Well, fls and other sleuthkit programs support split images. Will it fit if you divide it into several smaller files? Good idea: that's one possible solution. I would strongly advice you *not* to experiment with the original disk, because this *may* lead you to more problems. very good advice IMHO. Correct. I'm VERY careful with the original disk. But that's not the issue here. The file system itself is over 470GB (it occuples the whole 500GB disk), and while I do have spare 500GB disks, the whole image won't fit into a filesystem: it will be slightly too big. Maybe it will fit if you play with the newfs parameters of the new disk? Shrinking the reserved space, enlarging the block and fragment size and reducing the number of inodes, that kind of thing. If the file won't fit (still copying), I'll hook up a couple of 500GB disks to the box, and will try to newfs a bigger file system across all of them via gconcat(8). I haven't tried it before, but I hope it will work. Thanks for all the help. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
