# dd_rescue & changing block size



## Darin (Dec 27, 2001)

Forgive me for the stupid questions... I don't know anything about linux, and while I have upgraded TiVos before, I've never had problems doing it.
I have a previously upgraded HR10-250 (added 2nd 250GB to existing 250GB) that has been having some lock-up and reboot issues. As per this thread, I can't even seem to get through a standard (no recordings) back-up. It's been on "scanning source drive, please wait a moment" for well over 14hrs without even starting the backup process. So I'm thinking perhaps I need to try dd_rescue.

The new drives I have to replace the old ones are both 400gb. So I want/need to change the block size with the -s 4 option. Being a byte copy, I'm assuming that can't be done during the dd_rescue process(?). So at this point, should I dd_rescue each of the existing 250gb drives to the new 400gb drives, then take the new drives and do a standard back-up, then do a restore back to the new drives with the -s 4 option? Am I even on the right track?


----------



## JamieP (Aug 3, 2004)

Darin said:


> Forgive me for the stupid questions... I don't know anything about linux, and while I have upgraded TiVos before, I've never had problems doing it.
> I have a previously upgraded HR10-250 (added 2nd 250GB to existing 250GB) that has been having some lock-up and reboot issues. As per this thread, I can't even seem to get through a standard (no recordings) back-up. It's been on "scanning source drive, please wait a moment" for well over 14hrs without even starting the backup process. So I'm thinking perhaps I need to try dd_rescue.
> 
> The new drives I have to replace the old ones are both 400gb. So I want/need to change the block size with the -s 4 option. Being a byte copy, I'm assuming that can't be done during the dd_rescue process(?). So at this point, should I dd_rescue each of the existing 250gb drives to the new 400gb drives, then take the new drives and do a standard back-up, then do a restore back to the new drives with the -s 4 option? Am I even on the right track?


It's -r 4, not -s 4, and you only need it if you expanding by more than 274GB. 400 - 250 = 150 which is < 274GB, so you don't need to worry about this. Even if you did, it is at the mfsadd stage, when you are expanding to fill the drives, when you would use it. After the dd_rescue is complete you run mfsadd to expand into the full capacity of the destination drives.

Good luck.


----------



## Darin (Dec 27, 2001)

Yes, my bad on the switch. I see what you're saying about not NEEDING the larger block size, since there are already existing partitions that obviously must be 250GB or smaller that take up the entirety of each drive, so any new partitions can't be any bigger than the difference of the sum of the current partitions (per drive) and the size of the new drive. So 400-250. But am I correct in understanding that once a partition is created with a specific block size, that's what it's always going to be? When you say I'd use the -r 4 switch during mfsadd stage, that would just use the larger blocks for the NEW Partition(s), right? Since my situation would result in all partitions being 250gb or less, I may not NEED the larger partitions, but I've seen quite a few posts that have suggested it improves performance on units with larger drives. So there may be a desire to increase the block size (I can certainly say there's a HUGE desire for an increase in performance).

Thanks for the help!


----------



## JamieP (Aug 3, 2004)

Darin said:


> Yes, my bad on the switch. I see what you're saying about not NEEDING the larger block size, since there are already existing partitions that obviously must be 250GB or smaller that take up the entirety of each drive, so any new partitions can't be any bigger than the difference of the sum of the current partitions (per drive) and the size of the new drive. So 400-250. But am I correct in understanding that once a partition is created with a specific block size, that's what it's always going to be? When you say I'd use the -r 4 switch during mfsadd stage, that would just use the larger blocks for the NEW Partition(s), right? Since my situation would result in all partitions being 250gb or less, I may not NEED the larger partitions, but I've seen quite a few posts that have suggested it improves performance on units with larger drives. So there may be a desire to increase the block size (I can certainly say there's a HUGE desire for an increase in performance).
> 
> Thanks for the help!


You can't change the min allocation unit for the old partitions, only set it for new partitions you are adding.

I don't think anyone has done any careful measurements that support a conclusion that a larger min allocation unit improves performance. It seems like a plausible theory (e.g. mfs files may have fewer fragments), but I doubt it is a large effect, if it has any effect at all.


----------



## Darin (Dec 27, 2001)

JamieP said:


> You can't change the min allocation unit for the old partitions, only set it for new partitions you are adding.


Ok, this may be a part that I'm misunderstanding... if you do an mfsbackup without saving the recordings, then do a restore, are empty partitions written back to the new drive with the old parameters, with no chance to change the block size? Doing the back-up will divorce the two drives and create a single image, so obviously the partitions from the 2nd drive are gone. I figured that doing a restore/back-up would create new partitions on the new destination drives.



> I don't think anyone has done any careful measurements that support a conclusion that a larger min allocation unit improves performance.


Yes, it seems like everything, it all depends on who you ask.  But I've seen more "pro" large blocks than against. In fact, I've not really seen anything against, but perhaps not all agree that it helps performance. But I have seen several posts by some that the performance increase they've seen is not trivial. In fact, there was a post I saw where someone took their back-up, and restored it multiple times with and without the -r 4 option, and found very noticeable performance increases. In fact, if he did this, would that not answer my question about re-creating partitions?


----------



## JamieP (Aug 3, 2004)

Darin said:


> Ok, this may be a part that I'm misunderstanding... if you do an mfsbackup without saving the recordings, then do a restore, are empty partitions written back to the new drive with the old parameters, with no chance to change the block size? Doing the back-up will divorce the two drives and create a single image, so obviously the partitions from the 2nd drive are gone. I figured that doing a restore/back-up would create new partitions on the new destination drives.


If you make a sans-recordings backup ("shrunk" backup), all the expansion partitions are dropped and you only have the original set of MFS partitions that were on your original stock TiVo disk. In your case, you'll have the two partition pairs from your original 250GB A drive, and nothing on the B drive. So, yes, if you expand that backup onto a new larger disk (or pair of disks), you'll get additional expansion partitions. Note that in this case, you may in fact need the -r 4 switch, e.g. if you are expanding onto a 400GB B drive.


> Yes, it seems like everything, it all depends on who you ask.  But I've seen more "pro" large blocks than against. In fact, I've not really seen anything against, but perhaps not all agree that it helps performance. But I have seen several posts by some that the performance increase they've seen is not trivial. In fact, there was a post I saw where someone took their back-up, and restored it multiple times with and without the -r 4 option, and found very noticeable performance increases. In fact, if he did this, would that not answer my question about re-creating partitions?


Post a link, if you can find it again. I would expect that if there was a large performance difference, TiVo would be shipping stock drives with a larger minimum allocation unit.


----------



## Darin (Dec 27, 2001)

JamieP said:


> Post a link, if you can find it again.


It was harder than I thought! It was hiding in the archives: http://archive.tivocommunity.com/ti...10125&highlight=mfsrestore+and+menu+and+speed

Since running in to this upgrade problem yesterday, I've read TONS of posts, and they're starting to run together. But that's not the only one I saw that suggested that people have seen improvements with the larger block sizes. It's just the one that stood out as someone doing a back-back comparison. From my POV, there's really no downside outside of a VERY slight decrease in space utilization efficiency (which shouldn't be a concern with 800GB on tap), so if there's a chance that performance would increase, I'm certainly interested.


----------



## Darin (Dec 27, 2001)

So I ran dd_rescue on my first (original 250GB WD tivo A) drive, copying to one of the 400gb replacement drives. In the middle of the process, it did hit 8 errors, resulting in a total of 4kb that couldn't be copied. The whole process for the one drive took several hours. So since I _knew_ the A drive had a some errors, and wouldn't know about the B drive until letting dd_rescue run on it, I figured I'd try to do a backup from the new drive where the A data was copied to, paired with the original B drive, just to see if it would work without dd_rescuing the B drive. It hit a couple of errors, but was able to create a back-up within about five minutes.

Of course, now that I'm done, I'm not even sure I need it... Since I've already missed the show I wanted to record last night, I figure I may as well try out Zipper while I have the drives out, and I guess I don't HAVE to use my original back-up to do that.


----------



## JamieP (Aug 3, 2004)

Darin said:


> It was harder than I thought! It was hiding in the archives: http://archive.tivocommunity.com/ti...10125&highlight=mfsrestore+and+menu+and+speed
> 
> Since running in to this upgrade problem yesterday, I've read TONS of posts, and they're starting to run together. But that's not the only one I saw that suggested that people have seen improvements with the larger block sizes. It's just the one that stood out as someone doing a back-back comparison. From my POV, there's really no downside outside of a VERY slight decrease in space utilization efficiency (which shouldn't be a concern with 800GB on tap), so if there's a chance that performance would increase, I'm certainly interested.


Interesting. That's an old post. It's not clear to me if it was a Series 1 or Series 2 and what tivo software version was involved. It may or may not be relevant to current hardware and software versions. Perhaps you can try it both ways and make some concrete quantitative comparisons with current hardware/software.


----------



## Darin (Dec 27, 2001)

I don't think there were series 2 d-tivos four years ago, so I'd assume it's a series 1. Regardless though, if I understand everything correctly, I'm going to HAVE to use larger blocks if I'm upgrading to two 400GB drive from a no recording backup or virgin image. And I ASSUME that if I'm going to use zipper, keeping recordings isn't an option anyway (not that it matters - at this point I want to be as clean as possible).


----------

