1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Fixes for MFSTools 2.0 swap problems

Discussion in 'TiVo Upgrade Center' started by Robert S, Jul 31, 2002.

  1. Aug 15, 2002 #81 of 609
    Merle Corey

    Merle Corey New Member

    64
    0
    Aug 25, 2001
    Mount...
    Hey, I can aim for failure, too. I'll run with -r 2 tonight just to prove the point (probably).

    How big is big? I was planning on just going to 120GB for my new purchase, and merging it with the 40GB for large testing. That's more than a single 160GB, but it's way smaller than any dual-large config.

    (I'll freely admit that my curiosity and testing aren't entirely selfless - my 100GB drive has started making the kachunk-kachunk-kachunk of doom, and I'd rather get it out of my TiVo before it's dead. Gotta make sure I've got a clean upgrade path. :D)

    MC
     
  2. Aug 15, 2002 #82 of 609
    Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    If you can get a 120 + 40 to recover from a green screen, I'd be convinced (already close to convinced). You'd then have a two-drive configuration, much larger than any standard TiVo, which would cover most of the potential problems your current experiments haven't.
     
  3. Aug 15, 2002 #83 of 609
    Merle Corey

    Merle Corey New Member

    64
    0
    Aug 25, 2001
    Mount...
    Ok, so my current laundry list is:

    40 w/ -r 2: Proof of failure

    120+40 w/128MB swap & -r 0: Proof of success in large setups.

    120+40 w/64MB swap & -r 0: Proof of possible mfsfix swap requirement resolution (in 3.0 at least).

    Am I missing anything? Any requests? I'm limited by hardware to SA series 1 only, so I can't do any DTiVo experimentation.

    MC
     
  4. Aug 15, 2002 #84 of 609
    dobbie1

    dobbie1 Member

    169
    0
    Apr 15, 2002
    Memphis, TN
     
  5. Aug 15, 2002 #85 of 609
    sbourgeo

    sbourgeo Hepcat Daddio

    7,435
    0
    Nov 10, 2000
    New England
    I'd rather hold off on the klugey stuff (like the swap workarounds) until the process is ironed out a little.

    The TiVo I want to add it to is currently our "production" model and I want to minimize the risk as much as possible.


    Steve
     
  6. Aug 15, 2002 #86 of 609
    Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    If your swap is OK you'll see one line (very easy to miss) saying something like 'Activating swap <size>, priority -1'.
     
  7. Aug 15, 2002 #87 of 609
    dobbie1

    dobbie1 Member

    169
    0
    Apr 15, 2002
    Memphis, TN
    I rebooted, then activated backdoors, went to /var/log/kernel and did not see any entry as described above. The only entry close was "Initialize with 1 live caches."

    Thanks for your responses.
     
  8. Aug 15, 2002 #88 of 609
    Merle Corey

    Merle Corey New Member

    64
    0
    Aug 25, 2001
    Mount...
    Straight from my kernel log:

    Jan 1 00:00:15 (none) kernel: Activating swap partitions
    Jan 1 00:00:15 (none) kernel: Adding Swap: 130684k swap-space (priority -1)

    It's very early in the boot process (you can tell because the date/time isn't set yet), but it's pretty easy to miss. The line you're looking at is around (ballpark number, YMMV) 100 lines too far down. (Or, an unknown number too soon, depending on where your logfile starts.)

    Hope that helps!

    MC
     
  9. Aug 15, 2002 #89 of 609
    horwitz

    horwitz New Member

    70
    0
    Jan 11, 2002
    So what is the latest "best idea" for upgrading? I am going from a factory HDR312 (13.6+13.6) to 120. MFSTools 2.0 a la Hinsdale's page (what about all these flags people are talking about? -xp, -r 0, -s 128, etc.)? Will the old 1.1 solution on Hinsdale's page work; what disadvantages are there to the old procedure (aside from it taking longer)? BTW, I hope to upgrade to 120+120 sometime in the not-too-distant future.
     
  10. Aug 15, 2002 #90 of 609
    Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    As you might guess, this is still a matter for debate, however, I think we can say the following:

    If you want to be absolutely safe, stay away from MFS Tools 2.0! Use the older, proven tools in the original Hinsdale.

    If you have to use MFS Tools 2.0 (there are some upgrades that can not be done with the old tools), avoid the -s option (increase swap partition file) and use -r 0 to force 1Mb block size.

    The -x and -p options (you've combined them as -xp) cause MFS Tools to fill the hard drive with Tivo partitions and use an alternate partition layout that's believed to be faster.

    If you want the fastest possible TiVo and are prepared to accept the risk that your TiVo might lose all its recordings without warning (if you get filesystem corruption), use MFS Tools 2.0 as described in new Hinsdale, but check your swap as described in the first post in this thread.
     
  11. Aug 15, 2002 #91 of 609
    SAFW

    SAFW TiVophile

    18
    0
    Jun 11, 2002
    San...
    So does anyone know of a method to get MFStools 1.0 working with devices recognized as hdf, hdg, hdh, and hdi (the Promise RAID controller takes up hda, hdb, hdc, and hde)? How about TiVoMad? Is there an integrated restore/expand option like -zxpi in MFStools 2.0?

    MFStools 2.0 worked like a charm for me with -zxpi, but now I'm concerned that I'll get the GSOD somewhere down the line.

    SAFW
     
  12. Aug 15, 2002 #92 of 609
    Merle Corey

    Merle Corey New Member

    64
    0
    Aug 25, 2001
    Mount...
    I ran several tests tonight, and here are the results:

    First up, swap space tests. (All tests are to the same 40GB drive.) First with:

    mfsrestore -p -x -r 2 -i /mnt/bak/mybackup /dev/hdb

    I can confirm that the "default" swap works fine out of the gate. As expected, a 64mb swap partition was found on first boot; it's not a restored swap either, as the swap on my old drive was 128MB. So we have a little more confirmation on that front.

    A little weirder: I ran the experiment again, this time with the 128MB swap (-s 128), and rebuilt the swap (mkswap /dev/hda8 ; swapon -a) via telnet. The swap definitely mounted on the command, and remounted after rebooting, but no further log messages were generated by it. So everyone who couldn't find any message at all? You may not be crazy, and your swap may be fine. Don't ask me, I can't explain this one.

    A third time through, and I tried another swap prep mechanism: Building the swapfile with the mkswap on the bootdisk. I used: mkswap -v0 /dev/hdb8

    This worked. Flawlessly. Tricks involved were having byteswapping enabled and forcing the old style (-v0) swapfile. The default was to a new style swap - I knew something was up as soon as that happened because the messages were completely different. Forcing -v0 generated the same messages as doing mkswap via telnet to TiVo, and worked immediately on insertion.

    I'd love to hear from someone with a DTiVo who's willing to try this. rswift? I believe you were looking for a mechanism to fix your swap?

    Now for the really weird part: It successfully ran through mfsassert -please with -r 2. This surprised me so much that I ran it again after zeroing out the drive - and it worked again. So just for giggles, I ran it through a third time, this time without specifying any -r value (theoretically defaulting to -r 2, but I wasn't taking it for granted). It worked yet again.

    The only conclusions I can draw are either:

    1) -r works for all values and drive sizes, and any mfsassert/fsfix issues are unrelated

    2) -r works for all values of drives under a certain size, but fails for drives/combos over a certain size

    3) -r works with a stripped out backup (-s) but not for modifying "existing" data - preservation of programs, adding a B drive to an already expanded A drive, etc

    I'd love to prove #1 is true, but I suspect the reality is #2 or #3. It may be that only "native" MFST2 mods work, and that piggybacking with other expansion mods doesn't. It may be yet another space issue. I can't work any further on most of these until my new drive arrives (some time early next week, best guess).

    If anybody has anything further they'd like me to try, let me know. I plan to try again, this time to do a combo of:

    mfsrestore -p -r 0 -i /mnt/bak/mybackup /dev/hdb

    and

    mfsadd -r 2 -X /dev/hdb

    to simulate item #3 (as if the data had been dd'd over) and see if that makes anything break, but I'm not going to have time to do that until some time this weekend.

    MC
     
  13. Aug 16, 2002 #93 of 609
    stormsweeper

    stormsweeper How *you* doin'?

    424
    0
    Nov 27, 2001
    NYC, USA
    I think I was one of the first to report this on my SVR-2000. One part of the problem is that the older swap version is limited to 127MB. So you should get a message that the space was truncated to 133890048 or so when you run mkswap from the tivo.

    Since then it's been happy.
     
  14. Aug 17, 2002 #94 of 609
    dougdmy

    dougdmy New Member

    12
    0
    Jan 4, 2000
    Ft....
    I posted this in another thread, but thought that it was more appropriate to this thread.
    __________

    I used mfstools-2.0 and ran well for a couple of months. Then a few days ago, I had the GSOD/reboot loop problem. I had so many recordings on there, too. But I was very concerned about my Season Passes and Wishlists. Here's what I did:

    I took out the two 120GB drives from my TiVo and used mfstools-1.1 to create a backup image. I got a message stating something about an inode problem and that it was trying to read the backup table (or something to that effect). The backup successfully completed. Then I restored the image using mfstools-1.1 to a new 80GB drive. I put the 80GB drive in my TiVo. On power-up, I got the GSOD and much to my delight, it did not reboot. It spent about 20 minutes fixing itself and then it rebooted and all seemed well. I deleted what was listed in my Now Showing list, powered down, and TiVoMadded the 80GB drive to utilize the whole thing.

    So far (one day later) all seems well.

    This got me thinking. Can I use mfstools-1.1 to create a backup image of my original 120GB+120GB configuration (streams and all) and then use mfstools-1.1 to restore it? Hopefully during the restore process mfstools-1.1 will create the mfs partitions in a way that will allow mfsfix to do its job and I'll have minimal programming loss.

    Has anyone else tried this? It's an expensive thing for me to try because I would have to go out and buy enough disk space to store the huge backup file.

    I appreciate any and all suggestions or ideas.

    Doug (who is very sad because he lost the entire season of The Shield that he hasn't watched yet)
     
  15. Aug 17, 2002 #95 of 609
    Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    I think this has been tried, without success. One obvious question would be whether MFST1 can read the larger blocks created by MFST2 (your minimal backup only captures the original TiVo partitions (1Mb blocks, even on an MFST2 restore) and doesn't touch the new partitions).
     
  16. Aug 17, 2002 #96 of 609
    Merle Corey

    Merle Corey New Member

    64
    0
    Aug 25, 2001
    Mount...
    For what it's worth, I'm starting to suspect that the block size problem isn't.

    This morning's test run involved making a fresh backup of my original 100GB (20 hour image, TiVoMad expanded) drive with MFST1:

    mfstools backup -6so /mnt/bak/mybackup /dev/hdb

    I restored with MFST1 to a 40GB drive:

    mfstools restore -zi /mnt/bak/mybackup /dev/hdb

    This gave me a 20 hour, unexpanded image on my 40GB drive. Booted, confirmed functionality, and even ran mfsassert -please for kicks (fsfix was successful). I then went back and expanded with MFST2:

    mfsadd -r 2 -x /dev/hdb

    Booted again, confirmed everything was golden, mfsassert -please, and yet another successful run of fsfix.

    I'm starting to nurse a pet theory, and that theory is that the decreased swap needed by the larger block size may not be directly proportional to the increase in MFS block size.

    To put it differently: Kevin (klincoln) is the only other person to test MFST2 via mfsassert with a known good swap. He tested with dual 160's and a 64MB swap - if I'm right, he may need 128MB swap to make it work, even with the default (-r 2) MFST2 block size. Kevin? You still watching this? Wanna take a crack at it?

    Meanwhile, I can't find a way to break things with a 40GB drive, so there's nothing more I can do for now. My new drive is arriving Wednesday, and I should be done with burning it in by Friday. As an added bonus, I may be able to lay my hands (temporarily) on another 120GB drive, allowing me to test an extremely large (though 34GB shy of maxed out) config.

    MC
     
  17. Aug 17, 2002 #97 of 609
    Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    How about reducing your swap? You could try swapoff to turn off all swap. You could also try manufacturing a smaller swap file and using that. If you could find a threshold below which mfsfix wouldn't complete, that would be an interesting find.

    However, if you look at embeem's post on Tiger's MFS Tools 2 thread, it looks like he understands the swap issue.
     
  18. Aug 17, 2002 #98 of 609
    Merle Corey

    Merle Corey New Member

    64
    0
    Aug 25, 2001
    Mount...
    I'm a little confused now. We already know that swap plays a critical role in successfully running fsfix. Or are you suggesting the establishment of multiple data points, whereby we can determine the minimum amount of swap required by, say, 40GB at -r 0 vs -r 2, and by extension determine whether the the swap size is directly proportional to the block size?

    Heck, I think I may go do that anyway now, just for kicks. :D The real testing may once again have to wait for me to get the new drive, though, as I'm going to be playing with really small partitions to scale it down for 40GB (ballpark "minimum" at -r 0 should be around 18MB, meaning a theoretical 9MB for -r 2).

    I didn't get that out of it. He just asserted that there was a problem that prevented fsfix from running. He wasn't even certain that it was a MFST2 problem, and said he didn't have the resources to check.

    It may be that we're flogging a dead horse at this stage, but I'm not going to be satisfied without definitive success either.

    MC
     
  19. Aug 17, 2002 #99 of 609
    Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    Yes, exactly. If reducing the swap breaks mfsfix on a 40Gb (and it may well be it's too small, but you don't have a bigger drive ATM), you should be able to find a threshold that separates sufficient from insufficient swap. It might then be possible to estimate how much swap a given configuration requires, and to test the theory that higher -r numbers require less swap for mfsfix.

    To some extent you can't add much more to our knowledge because we need more data from other TiVoes (there are enough people reporting GSOD loops to suggest it's a real problem). On the other hand, if you're enjoying the investigation I'm happy to suggest new experiments. You've certainly shown that saying 'MFST2 breaks mfsfix' is an over-simplification.

    I've PM'd embeem to ask what his config was - there's no earthly point in arguing what someone else meant :)
     
  20. jhburke

    jhburke New Member

    5
    0
    Aug 3, 2002
    Darien, IL
    I just wanted to post my confirmation of Merle Corey's findings about running mkswap from the boot disk. I had previously tried to run mkswap from the MFSTools 2.0 cd boot disk, and ended up with a swap file which I could mount from the boot disk, but would not mount from the TiVo. Now, thanks to Merle, I ran "mkswap -v0 /dev/hdc8" from a byteswapped boot cd, and my kernel logs now show "Adding Swap: 130744k swap-space (priority -1)". I also received the error message from the boot disk about truncating the swap file from 133xxxK to 130xxxK as Merle also noted. I don't notice anything running any faster on the TiVo, however.

    I'd be willing to try mfsassert -please, but since I have a DTiVo, I can't easily get a prompt. I guess I'll just have to wait for the green screen!

    BTW, I've had 2 TiVos now for greater than 2 and 1 years, and have never seen the green screen, either before or after upgrading. Are they common or am I just having good luck?

    John
     

Share This Page