Date: Tue, 14 Apr 2009 19:48:16 +0200 From: cpghost <cpghost@cordula.ws> To: Polytropon <freebsd@edvax.de> Cc: freebsd-questions@freebsd.org Subject: Re: Block device to regular file? Message-ID: <20090414174816.GA80513@phenom.cordula.ws> In-Reply-To: <20090414191843.c32e7f93.freebsd@edvax.de> References: <20090414161724.GA3721@phenom.cordula.ws> <20090414191843.c32e7f93.freebsd@edvax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 14, 2009 at 07:18:43PM +0200, Polytropon wrote: > On Tue, 14 Apr 2009 18:17:24 +0200, cpghost <cpghost@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/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090414174816.GA80513>