mfstools question

[FredThompson]

This post is a split from the sticky thread about extraction from drives connected to a PC. What's happened to me doesn't really fit in that thread but the scenario could happen to other people so I'm posting in this forum.

Basically, my xtreme 252/xupgrade T60 had a drive flake (stuttering, clunking sound, sometimes caused by fault, sometimes caused by bad connections.) The goal is to somehow get the stored recordings from the drive. The data on the discs should still be ok, assuming there is a way to read the sectors.

Riley suggested using MFSTools to combine the 2 original drives onto 1 destination drive then reboot the TiVo with that. In any event, putting all the files on one drive will make it a heck of a lot esier to work with.

Problem is, MFSTools is puking. My setup was:

hda - new destination drive
hdb - CD (snoopy's ISO w/MFSTools)
hdc - old A drive
hdd - old B drive

command used:

mfsbackup -Tao /dev/hdc /dev/hdd | mfsrestore -s 127 -xzpi - /dev/hda

reply from MFSTools:

/dev/hdd2: Success
/dev/hdd3: Illegal seek
mfs_load_volume_header: Total sectors (79358976) mismatch with volume header (199418880)
mfs_load_volume_header: Loading anyway
mfs_load_zone_map: Primary zone map corrupt, loading backup
mfs_load_zone_map: Secondary backup corrupt, giving up.
mfs_load_zone_map: Zone map checksum error!
mfsbackup: Backup failed to startup. Make sure you specified the right device, and that the drives are not locked.
Restre failed: -: Success

-- ok, any suggestions what to do now? I should point out that the PC has the nvidia chipset. IIRC, Linux kernal after 2.4.21 supports it properly. The kernal on the MFSTools floppies does not.

[BubbleLamp]

Don't think anything other than the CD should be hda, due to byteswapping.

You've already determined in another long thread that this chipset has issues, so why not try another machine?

[FredThompson]

hdd3 is reports as having the problems. Isn't that the old A drive?

What the other thread determined was the old Linux kernal on the MFS Tools floppy images doesn't support the nvidia chipset. Newer versions are just fine. Xtreme, xupdate and snoopy's seem to work just fine.

Can't imagine hdd3 has anything to do with ide 0 master but I'll try swapping master and slave on that controller to see if it matters.

[BubbleLamp]

Originally posted by FredThompson
hdd3 is reports as having the problems. Isn't that the old A drive?

What the other thread determined was the old Linux kernal on the MFS Tools floppy images doesn't support the nvidia chipset. Newer versions are just fine. Xtreme, xupdate and snoopy's seem to work just fine.

Can't imagine hdd3 has anything to do with ide 0 master but I'll try swapping master and slave on that controller to see if it matters.

What I was worried about is your target drive is on hda. It was always my understanding that the Tivo drives needed to be on byte-swapped IDE ports.

As for the error, I'd say the MFS's directory is sufficiently hosed to make reading impossible. This gets back to your attempt to try and use an OnTrack-like app to retrieve the files. So unless someone knows how to manually rebuild the MFS directory, I can't see how you'll get the files back.

[FredThompson]

I think you completely misunderstood the posts about Ontrack. That was being applied to an NTFS drive. The problem there was Windows needing the lba48 patch which I assumed had been included in Win2K SP4 because the tech note listed it as a requirement for SP1, 2 and 3, not 4. Apparently, once an attempt was made to write beyong 137G, the resultant crash hoses up the primary-level pointers on an NTFS volume so you're completely screwed. Ontrack's tools would have worked except NTFS doesn't include file ID in each cluster the way FAT and FAT32 work.

I'll try moving the CD to hda and see how that works. Until now, I've run hda as Win boot, hdb as CD and hdc and hdd as TiVo targets. You're right, there are issues with hda so maybe it wouldn't work anyhow. It really does look like this content is lost, though.

[BubbleLamp]

Originally posted by FredThompson
I think you completely misunderstood the posts about Ontrack. That was being applied to an NTFS drive. The problem there was Windows needing the lba48 patch which I assumed had been included in Win2K SP4 because the tech note listed it as a requirement for SP1, 2 and 3, not 4. Apparently, once an attempt was made to write beyong 137G, the resultant crash hoses up the primary-level pointers on an NTFS volume so you're completely screwed. Ontrack's tools would have worked except NTFS doesn't include file ID in each cluster the way FAT and FAT32 work.


Got ya, sorry for the mix up.

And just think what we can look forward to with WinFS!!

BTW, for years MS touted NTFS performance, but when pressed, they'd admit that FAT actually ran faster!

[FredThompson]

FAT bogs down when you do a huge amount of file moves. What happens is there are lots of left-over empty directory entries and they each have to be parsed to read the entire directory. FAT also doesn't seem to do that great a job with large drives and small files because the clusters get so big. I used to reboot 2-3 times/day with FAT32 because of this. NTFS doesn't have the same problem but it can also be brought to its knees.

On the flip side, it's wickedly easy to byte-edit FAT or FAT32 to recover or modify structures. Interestingly, it's based on Atari 8bit DOS structures (the source for which is the computer code scrolling through Arnold's head in the first Terminator movie.) Used to be able to follow a sector/cluster chain without needing the directory entry. Sure made recovery more robust. Wish we had some form of aggressive recovery for crashed TiVo volumes. Wonder what would truly be involved in hacking in a true journaling file system...

[BubbleLamp]

Originally posted by FredThompson
FAT bogs down when you do a huge amount of file moves. What happens is there are lots of left-over empty directory entries and they each have to be parsed to read the entire directory. FAT also doesn't seem to do that great a job with large drives and small files because the clusters get so big.

Let's just say when it came to publishing perfomance results some years ago, they wanted us to use FAT for our tests. ;)

[FredThompson]

It's really weird, some things run faster, some don't. I've watched command-line utils run faster on Win2K than Win98. Can't really say about the file systems. I do a lot of uncompressed or DV work and FAT32 just won't work well for me. Apparently, it works great with Linux. Frankly, I'd rather run FAT32 except the issues I mentioned create problems for me daily.

Hmmm...maybe a Linux file server would be the better solution. Win boxes with a C drive only and fiber to the server. It's only money...

[rc3105]

try this with the original drives on /dev/hdc /dev/hdd and the new drive on /dev/hda. boot without byteswapping from whatever kernel your box likes and use the staticly compiled version of mfstools 2.0

mfstool backup -s /dev/hdc /dev/hdd | mfstool restore -i - /dev/hda

this will give you a fast (like 5 mins) copy with season passes & all intact. the recordings will be listed in NowPlaying but they won't actually contain any video - you can use nowshowing.tcl or mfs_ftp or whatever to get the fsid numbers. then use those fsid numbers & the procedures in the direct extraction thread on the 2 original drives

if mfstools can't read enough of the drives (only about a gig) to do a backup w/o video then you're outta luck


--
Riley

[rc3105]

Originally posted by FredThompson
Hmmm...maybe a Linux file server would be the better solution. Win boxes with a C drive only and fiber to the server. It's only money...
if you're going to use a linux / ext3 server as NAS, you might consider running tcp over firewire instead of fibre

plenty fast in my exp & MUCH cheaper. you prolly allready got the cables layin around :p


--
Riley