Block device to regular file?

[cpghost]

On Tue, Apr 14, 2009 at 07:18:43PM +0200, Polytropon wrote:
> On Tue, 14 Apr 2009 18:17:24 +0200, cpghost <cpghost at 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/