# S3 Consolidation while preserving recordings



## cniessen (Jan 10, 2004)

I wanted to share some of my experiences with the group, in case it helps other people. With the help of jmbach, and dougdingle, I was trying to consolidate my S3 OLED which has the original internal drive (250GB) and a 1 TB external drive onto a single 2TB drive. The process was reasonably straightforward once I got the source for the mfstools from the MFSLive CD and fixed the code to properly handle drives larger than 1TB. I used the procedure laid out in
http://www.tivocommunity.com/tivo-vb/showthread.php?p=9915514#post9915514
which worked successfully.

But dougdingle mentioned that he had a S3 that he had not been able to upgrade because it had already had its internal drive expanded. So I wanted to see if I could understand the process better.

Here is my understanding of how things work. Someone please correct me if I am wrong on any of this stuff... Some of it is obvious and well-trod knowledge, but I'm trying to piece things together here...

The TiVo has multiple media regions on disk (these are typically the "Media Partitions" in the partition map). However, the way the TiVo keeps track of the various partitions and available space is via the zone map data structures. This is a linked list of structures that has the head in the first application zone. (It may be pointed to in the MFS super block; I'm not sure about that, but the TiVo knows how to find the first zone map, and once it finds the first one, the rest chain off from there.) The zone maps come in three different flavors that describe different things (inodes, application regions, media regions). The way that the tivo points to things on the disk(s) is via sectors. However, the sectors are not the same as the sectors on the disk. (They are the same size, but sector X on disk does not necessarily correspond to sector X in the TiVo's idea of sectors.)

The MFS superblock contains a list of partitions (the devlist). The tivo loads each partition in the order given. The way the TiVo addresses things by sector is by making a contiguous "address space" of sectors by just appending each partition's sectors as the are loaded. So if the devlist contains "/dev/hda10 /dev/hda11 /dev/hda12 /dev/hda13", and those partitions have 10, 20, 30, and 40 sectors respectively, then the contents of hda10 are sectors 0-9, hda11 is 10-29, hda12 is 30-59, and hda13 is 60-99. These partitions may be anywhere on the disk, and they may be on other disks, but they just get loaded contiguously for the purpose of calculating sector addresses.

The zonemaps work in sector addresses, so when the TiVo goes looking for something at sector X, it figures out which partition that sector lies in, then takes the offset into that partition. So as long as you make sure that the partitions are loaded in order, and they are the right size, they can be anywhere. And also, the partition numbers indexed by their order in the partition map, not their order on disk. For example, on the internal drive for my S3 TiVo, the partition map looks like


```
Partition map (with 512 byte blocks) on '/deskstar/s3-internal-disk.dd'
 #:                type name                        length   base      ( size )
 1: Apple_partition_map Apple                           63 @ 1        
 2:               Image Bootstrap 1                      1 @ 268618469
 3:               Image Kernel 1                      8192 @ 268618470 (  4.0M)
 4:                Ext2 Root 1                      524288 @ 268626662 (256.0M)
 5:               Image Bootstrap 2                      1 @ 269150950
 6:               Image Kernel 2                      8192 @ 269150951 (  4.0M)
 7:                Ext2 Root 2                      524288 @ 269159143 (256.0M)
 8:                Swap Linux swap                  262144 @ 269683431 (128.0M)
 9:                Ext2 /var                        524288 @ 269945575 (256.0M)
10:                 MFS MFS application region      589824 @ 270469863 (288.0M)
11:                 MFS MFS media region         216747657 @ 271649511 (103.4G)
12:                 MFS MFS application region 2    589824 @ 271059687 (288.0M)
13:                 MFS MFS media region 2       268618405 @ 64        (128.1G)

Device block size=512, Number of Blocks=488397168 (232.9G)
DeviceType=0x0, DeviceId=0x0
```
Note that the last partition in the map is actually describing a partition thats first on the disk (media region 2, /dev/hda13). TiVo does this so that the OS is physically in the middle of the disk, with big media partitions on either side to keep the average seek distance down.

When TiVo looks at a partition, it actually rounds the sectors in the partition down to the nearest multiple of 1024. So if you look at /dev/hda11 in the above, its a wierd size (216747657), and is not a multiple of 1024 sectors. I'm not sure why TiVo did this; this is the unmodified disk that came with the unit. So even though the partition is a weird size, TiVo will only consider the partition to have 216747008 sectors. There are 649 sectors at the end of the partition that aren't used. This is important, because when TiVo is counting sectors, it uses the rounded-down number, not the actual size of the partition on disk.

You can see the size of the partitions (as used by TiVo) with mfsinfo.

```
---------------------------------------------------------------------
Super Header
	state=0 magic=abbafeed
	devlist=/dev/hda10 /dev/hda11 /dev/hda12 /dev/hda13 /dev/hdc2 /dev/hdc3
	zonemap_ptr=1121 total_secs=2440069120
---------------------------------------------------------------------
MFS volume set for /deskstar/s3-internal-disk.dd and /deskstar/s3-external-disk.dd
The MFS volume set contains 6 partitions
   Partition     sectors         size
  /deskstar/s3-internal-disk.dd10        589824          288 MiB
  /deskstar/s3-internal-disk.dd11     216747008       105833 MiB
  /deskstar/s3-internal-disk.dd12        589824          288 MiB
  /deskstar/s3-internal-disk.dd13     268617728       131161 MiB
  /dev/hdc2          4096            2 MiB
  /dev/hdc3    1953520640       953867 MiB
Total MFS sectors: 2440069120
Total MFS volume size: 1191440 MiB
Estimated hours in a standalone TiVo: 1480
---------------------------------------------------------------------
```
(Note that I'm actually using images of the disks, not the disks themselves. The name of the partitions look a little weird, but everything else is exactly the same.)

So /dev/hda11 is the 11th partition on the internal disk, which from the partition map is 216747657 sectors, but in the MFS volume set is 216747008 sectors. So when TiVo is counting sectors, sectors 0-589823 are on /dev/hda10, then 589824 - 217336831 are on /dev/hda11, then 217336832 - 217926655 are on /dev/hda12, and so on. The partitions on the external disk (/dev/hdc2 and /dev/hdc3) just get loaded sequentially as well; the fact that they happen to be on another disk is just kept track of in the devlist. The list of sectors that TiVo uses is contiguous across all volumes.

So when the TiVo looks at the disks, it loads the partitions in the order listed in the devlist, and builds the mapping of "TiVo sectors" to hard disk sectors. Once that is done, the distinction of where partition boundaries are seems to be lost. This is why the trick of collapsing or coalescing multiple partitions into one (as referenced in the thread mentioned above) works. If you take partitions that are contiguous in load order (meaning their partitions are sequential in the devlist) and you concatenate them, and you increase the size of the entry in the partition map to include the added data, then the whole big block will be loaded and the data in the concatenated partitions will be found just fine. A few things to remember, though. If you are going to concatenate one partition onto the end of another, you need to add the data starting at the end of the active part of the partition, if the partition isn't a multiple of 1024 sectors. Otherwise, the "unused" sectors at the end of the first partition will get included when the partition is loaded which will screw up the sector counts, and will make all of the sector offsets be wrong. (Meaning that the zonemaps will not be where they are supposed to be, and nothing will work.) The other thing is that you can only concatenate partitions if they are sequential in load order. Partitions that are physically adjacent on disk might not be adjacent in load order, so you can't assume that partitions that are adjacent on disk can be combined. Load order is dictated by the devlist.

So as long as you keep these rules in mind, you can move partitions around, change the order in the devlist, reorder the partition map, etc, as long as the result is that the data will all be loaded in the same order.

One other side note: it appears that if the TiVo starts up and finds that some of the partitions in the devlist don't exist, and your TiVo has an external drive, then it will bring up the "I can't find the external drive. Do you want to divorce it?" screen. Then, when you tell it to go ahead, it loads all the partitions in the devlist, then starts looking at all of the shows in the filesystem. It will delete any shows that it doesn't have all of the data for, but keep all of the ones that it does have all of the data for. So in the earlier thread, the idea is that we take the data from the partitions that used to be on the external drive, concatenate them into an existing partition on the internal drive, and change the partition map so that there is one entry that includes the sectors from all three partitions. That way, when the TiVo boots, it will load all of the data (because all of the sectors are now contained in the remaining partitions), but it will see some partitions are missing, and bring up the divorce screen, and do the divorce process. During the divorce process, it won't find any sectors missing, so it will complete successfully, and keep all of the recordings.

So given this knowledge of a set of behaviors, I wanted to see if I could combine a setup like Doug's, with an expanded internal drive and an external drive. I took a couple of 1 TB drive and copied (just using dd) my real internal and external drives onto them. I then ran mfsadd to expand the internal drive, and offered it to the TiVo, and it was perfectly happy with this pair. It found and used the additional partition pair.

So the partition map for the internal disk is

```
Partition map (with 512 byte blocks) on '/dev/sdc'
 #:                type name                         length   base       ( size )
 1: Apple_partition_map Apple                            63 @ 1         
 2:               Image Bootstrap 1                       1 @ 268618469 
 3:               Image Kernel 1                       8192 @ 268618470  (  4.0M)
 4:                Ext2 Root 1                       524288 @ 268626662  (256.0M)
 5:               Image Bootstrap 2                       1 @ 269150950 
 6:               Image Kernel 2                       8192 @ 269150951  (  4.0M)
 7:                Ext2 Root 2                       524288 @ 269159143  (256.0M)
 8:                Swap Linux swap                   262144 @ 269683431  (128.0M)
 9:                Ext2 /var                         524288 @ 269945575  (256.0M)
10:                 MFS MFS application region       589824 @ 270469863  (288.0M)
11:                 MFS MFS media region          216747657 @ 271649511  (103.4G)
12:                 MFS MFS application region 2     589824 @ 271059687  (288.0M)
13:                 MFS MFS media region 2        268618405 @ 64         (128.1G)
14:                 MFS New MFS Application            2048 @ 488397168  (  1.0M)
15:                 MFS New MFS Media             865107968 @ 488399216  (412.5G)
16:          Apple_Free Extra                     600017984 @ 1353507184 (286.1G)

Device block size=512, Number of Blocks=1953525168 (931.5G)
DeviceType=0x0, DeviceId=0x0
```
and the partition map for the external disk is

```
Partition map (with 512 byte blocks) on '/dev/sdd'
 #:                type name                       length   base       ( size )
 1: Apple_partition_map Apple                          63 @ 1         
 2:                 MFS MFS application region       4096 @ 64         (  2.0M)
 3:                 MFS MFS media region       1953521008 @ 4160       (931.5G)

Device block size=512, Number of Blocks=1953525168 (931.5G)
DeviceType=0x0, DeviceId=0x0
```
and MFSInfo for the combined pair gives

```
---------------------------------------------------------------------
Super Header
      state=0 magic=abbafeed
      devlist=/dev/hda10 /dev/hda11 /dev/hda12 /dev/hda13 /dev/hdc2 /dev/hdc3 /dev/hda14 /dev/hda15
      zonemap_ptr=1121 total_secs=3305179136
---------------------------------------------------------------------
MFS volume set for /dev/sdc and /dev/sdd
The MFS volume set contains 8 partitions
   Partition     sectors         size
  /dev/sdc10        589824          288 MiB
  /dev/sdc11     216747008       105833 MiB
  /dev/sdc12        589824          288 MiB
  /dev/sdc13     268617728       131161 MiB
  /dev/hdc2          4096            2 MiB
  /dev/hdc3    1953520640       953867 MiB
  /dev/sdc14          2048            1 MiB
  /dev/sdc15     865107968       422416 MiB
Total MFS sectors: 3305179136
Total MFS volume size: 1613857 MiB
Estimated hours in a standalone TiVo: 2011
---------------------------------------------------------------------
```
So you can see how the partition I added with mfsadd got stuck on the end of the load order. If the internal disk had been expanded before the external disk was added, those partitions would have showed up before the /dev/hdc partitions in the devlist.

Note that since I copied everything with dd, the original partition (with odd partition sizes) was retained. If you copy things with MFS backup/restore, that makes partitions without extra sectors on the end.

Also note that I used a slightly tweaked version of mfsadd that allows me to hold back some sectors when adding the new partition. The 2TB drive I was using to test combining on is just a little smaller than the combined size of the two 1 TB drives I was using. So I made the added partition a little smaller so that everything would fit. That's why there is a free partition at the end of the disk. It might or might not be there on other systems.

So for this arrangement on disk, TiVo maps sectors to partitions as follows:

```
hda10:          0 - 589823
hda11:     589824 - 217336831
hda12:  217336832 - 217926655
hda13:  217926656 - 486544383
hdc2:   486544384 - 486548479
hdc3:   486548480 - 2440069119
hda14: 2440069120 - 2440071167
hda15: 2440071168 - 3305179135
```
We can re-arrange things as we see fit, as long as the data ends being loaded in the correct order.

I started by copying the contents of the internal drive onto a 2TB drive just using dd. Then the problem was how to copy the contents of the external drive (hdc2 and hdc3) and stuff them into an existing partition. The data needs to get loaded right after hda13. But hda13 is at the start of the disk, so there is no room after that. So I decided to put the data at the front of hda14, and change the devlist to move the references to the external partitions to the end. (Those partition reference will be to the no-longer-existing disk that triggers the divorce. I don't know what TiVo would do if the missing partitions are in the middle of the devlist; I probably wouldn't be happy at all, because if the partitions are missing, partitions that are after it in the devlist can't load properly, since the sector numbers would be all wrong.)

I copied all of the data from the external disk and put it at where hda14 starts, then I copied the data from the real hda14 after the external disk's data. I changed the entry in the partition map to make the size of hda14 big enough to encompass all of this data. I also had to re-copy the data from the real hda15, since that partition got moved on disk to accommodate the data from the external drive. I also had to fix the partition map to create the corrected hda15.

To accomplish these moves/copies, I just used dd:

```
dd if=/dev/sdd of=/dev/sdh bs=512 seek=488397168 skip=64
dd if=/dev/sdc of=/dev/sdh bs=512 seek=2441921904 skip=488397168 count=2048
dd if=/dev/sdc of=/dev/sdh bs=512 seek=2441923952 skip=488399216 count=865107968
```
For me, /dev/sdc was the 1TB internal disk, /dev/sdd was the 1TB external disk, and /dev/sdh was the 2TB target disk.

(As an aside, the commands I actually used were slightly different, because doing the dd with 512B blocks was really slow. Using 8KB blocks was about 10 times faster. So in the above, I just changed the bs=512 to bs=8k, then divided all of the numbers by 16. I could do that since they were all multiples of 8KB.)

The adjusted partition map looks like

```
Partition map (with 512 byte blocks) on '/dev/sdh'
 #:                type name                        length   base       ( size )
 1: Apple_partition_map Apple                           63 @ 1         
 2:               Image Bootstrap 1                      1 @ 268618469 
 3:               Image Kernel 1                      8192 @ 268618470  (  4.0M)
 4:                Ext2 Root 1                      524288 @ 268626662  (256.0M)
 5:               Image Bootstrap 2                      1 @ 269150950 
 6:               Image Kernel 2                      8192 @ 269150951  (  4.0M)
 7:                Ext2 Root 2                      524288 @ 269159143  (256.0M)
 8:                Swap Linux swap                  262144 @ 269683431  (128.0M)
 9:                Ext2 /var                        524288 @ 269945575  (256.0M)
10:                 MFS MFS application region      589824 @ 270469863  (288.0M)
11:                 MFS MFS media region         216747657 @ 271649511  (103.4G)
12:                 MFS MFS application region 2    589824 @ 271059687  (288.0M)
13:                 MFS MFS media region 2       268618405 @ 64         (128.1G)
14:                 MFS New MFS Application     1953526784 @ 488397168  (931.5G)
15:                 MFS New MFS Media            865107968 @ 2441923952 (412.5G)
16:          Apple_Free Extra                    599997248 @ 3307031920 (286.1G)

Device block size=512, Number of Blocks=3907029168 (1.8T)
DeviceType=0x0, DeviceId=0x0
```
So you can see that the "New MFS Application" partition is now huge, since it contains the data from the external disk.

When I run mfsinfo on it, I get

```
---------------------------------------------------------------------
Super Header
      state=0 magic=abbafeed
      devlist=/dev/hda10 /dev/hda11 /dev/hda12 /dev/hda13 /dev/hda14 /dev/hda15 /dev/hdc2 /dev/hdc3
      zonemap_ptr=1121 total_secs=3305179136
---------------------------------------------------------------------
MFS volume set for /dev/sdh
The MFS volume set contains 8 partitions
   Partition     sectors         size
  /dev/sdh10        589824          288 MiB
  /dev/sdh11     216747008       105833 MiB
  /dev/sdh12        589824          288 MiB
  /dev/sdh13     268617728       131161 MiB
  /dev/sdh14    1953526784       953870 MiB
  /dev/sdh15     865107968       422416 MiB
  /dev/hdc2             0            0 MiB
  /dev/hdc3             0            0 MiB
Total MFS sectors: 3305179136
Total MFS volume size: 1613857 MiB
Estimated hours in a standalone TiVo: 0
---------------------------------------------------------------------
```
You can see that I've reordered the devlist to move the reference to hdc2 and hdc3 to the end of the list. (You might have to scroll the text box above to the right to see it.) That way the TiVo will see them as missing, but won't give up on other partitions that would otherwise have followed them.

mfsinfo shows /dev/hdc2 and /dev/hdc3 as 0 size because they are missing. If I take the reference to /dev/hdc2 and /dev/hdc3 out of the devlist, mfsinfo is completely happy with the consolidated disk, and reads and validates the zonemaps without a problem. But if I put it into the TiVo like that (with hdc2 and hdc3 not in the devlist), it would complain about an incorrect storage device. But with the references to hdc2 and hdc3 back in the devlist, it figures out that it needs to divorce the disk.

So to test it out, I offered the disk to the TiVo and it did what was expected. It did the divorce (which took 5-10 minutes or so), then rebooted and all of the recordings were still there, and the TiVo reported the correct size.

Looking at the drive post-divorce with mfsinfo shows:

```
---------------------------------------------------------------------
Super Header
      state=0 magic=abbafeed
      devlist=/dev/hda10 /dev/hda11 /dev/hda12 /dev/hda13 /dev/hda14 /dev/hda15
      zonemap_ptr=1121 total_secs=3305179136
---------------------------------------------------------------------
MFS volume set for /dev/sdh
The MFS volume set contains 6 partitions
   Partition     sectors         size
  /dev/sdh10        589824          288 MiB
  /dev/sdh11     216747008       105833 MiB
  /dev/sdh12        589824          288 MiB
  /dev/sdh13     268617728       131161 MiB
  /dev/sdh14    1953526784       953870 MiB
  /dev/sdh15     865107968       422416 MiB
Total MFS sectors: 3305179136
Total MFS volume size: 1613857 MiB
Estimated hours in a standalone TiVo: 2011
---------------------------------------------------------------------
```
and we can see that the TiVo got rid of the reference to /dev/hdc2 and /dev/hdc3.

So the point of this exercise was to show what you can do if you stay within the rules. I tried to do some of this with MFS backup/restore, but that doesn't seem to deal properly with partitions that have been consolidated (and that required me to modify the source volume). It also doesn't deal well at all with creating a destination volume with more than 16 partitions. (The TiVo can't deal with that disk, but I might have wanted it to just do the copy, and then I would consolidate the partitions post-restore.) MFS restore has the 16 partition limit hard coded in a number of places, so it looked like it was going to be a pain to modify. Its not clear what the backup/restore approach does for you if you're copying all of the video streams. If you're copying all of the data, you can accomplish the same thing with dd. But for normal operations, backup/restore are much easier to use, and a lot more failsafe. And they make nice even partitions.

But you could accomplish all of that (partition aligning, moving, reordering, etc) with dd and pdisk. The only thing magic I used was a quick tool to allow manipulation of the devlist. I did all of the above using Debian 12.04 LTS.


----------



## unitron (Apr 28, 2006)

I can see I have some serious reading to do.


----------



## ggieseke (May 30, 2008)

Excellent writeup. :up:

Knowing that the MFS partitions are rounded down to even multiples of 1024 sectors is key when translating logical sector numbers to physical locations on the disk(s). That threw me off for several days when I was writing DvrBARS until I spotted a comment in the MFSLive source code.

P.S. The first zonemap is indeed part of the MFS super header.


----------



## jmbach (Jan 1, 2009)

All I can say is brilliant!!!!

PS. In windows one can use iBored to copy partitions over individually. (There is also a Mac version of the same tool)


----------



## dougdingle (Jul 4, 2007)

Nicely done! Glad to have been a *very *small part of your inspiration to dig further.

Gonna consolidate the two into a single 2TB this weekend!

Great job. Thanks.


----------



## cniessen (Jan 10, 2004)

dougdingle said:


> Nicely done! Glad to have been a *very *small part of your inspiration to dig further.
> 
> Gonna consolidate the two into a single 2TB this weekend!
> 
> Great job. Thanks.


Thanks for the info that got me started.

What does the devlist look like on your unit with the expanded internal drive? If the external drive partitions are last in the devlist, you should be able to do everything just fine using pdisk and dd. If the devlist has the external partitions somewhere in the middle, then you'll need to re-write the devlist to move them. I'm happy to share the quick and dirty tool I wrote, but its not part of any bootable mfstools image. So if you can find a way to use it (put it on a thumb drive and use the mfstools ISO that jmbach built? Use an Ubuntu live CD?), I'm happy to send it over.

Also, in your experience, you had some weirdness with the pdisk you were using, where you had to manually manipulate the partition count using ibored. I'm using a version of pdisk thats patched from the latest apple source. (I posted diffs in the original thread.) If you see weirdness when you're manipulating the partition table, I'd be more than happy to share that too.

Good luck, and let me know how you make out.


----------



## jmbach (Jan 1, 2009)

His dev list has the external drive at the end. After reading your excellent write up on your research, we are going to create a "TiVo optimized image" from his internal 1TB and external 500GB drive. Since the internal drive has been expanded, all the MFS partitions are a multiple of 1024. So our plan is to move partitions 11, 12, 13, 14, and 15 to the front of the disk and coalesce 11, 12, and 13 into partition 11, and 14 and 15 into partition 12. Then place the external drive partitions at the other end of the OS and coalesce them into partition 13. Allow the TiVo to boot and divorce the missing devs in the dev list. Then use MFSAdd to expand the rest of the drive. 

Will let you know how it works out tomorrow. 

Sent from my SPH-L710 using Tapatalk


----------



## dougdingle (Jul 4, 2007)

And it worked out perfectly!

jmbach sent me an APM file to use as a template when doing the copying of partitions (I used iBored), then when that was done, I copied a second "coalesced" APM template to the destination drive which reflected the new partition arrangement, then into the TiVo, divorced the (no longer there) external drive, and it booted with all programs intact. Then used mfsadd from the modified mfslive, and supersize from winmfs, and I now have a single 2TB with 318 hours capacity.

Here's the MFSinfo of the final drive (which is online now getting the 'm' update):

Mfsinfo (Drive 2)

Boot Page
Boot Page: root=/dev/hda4
Active Boot Partition: 3 Active Root Partition: 4
Backup Boot Partition: 6 Backup Root Partition: 7

MFS Super Header
state=0 magic=abbafeed
devlist=/dev/hda10 /dev/hda11 /dev/hda12 /dev/hda13 /dev/hda14 /dev/hda15
zonemap_ptr=1121 total_secs=3905174528

Zone Maps
Z0:	type=0
map_start=1121 map_size=1 backup_map_start=589822
next_map_start=263266 next_map_size=9 next_backup_map_start=589813
zone_first=1122 zone_last=263265 zone_size=262144 min(chunk)=262144
free=262144 checksum=ba10266e logstamp=20936568 num_bitmap=1
Z1:	type=2
map_start=263266 map_size=9 backup_map_start=589813
next_map_start=263275 next_map_size=34 next_backup_map_start=589779
zone_first=589824 zone_last=217329663 zone_size=216739840 min(chunk)=20480
free=266240 checksum=9cbc5ac3 logstamp=20936574 num_bitmap=15
Z2:	type=1
map_start=263275 map_size=34 backup_map_start=589779
next_map_start=217336832 next_map_size=1 next_backup_map_start=217926655
zone_first=263309 zone_last=589772 zone_size=326464 min(chunk)=8
free=31680 checksum=6073d045 logstamp=20936630 num_bitmap=17
Z3:	type=0
map_start=217336832 map_size=1 backup_map_start=217926655
next_map_start=217598977 next_map_size=130 next_backup_map_start=217926525
zone_first=217336833 zone_last=217598976 zone_size=262144 min(chunk)=262144
free=262144 checksum=e1c31b40 logstamp=20936568 num_bitmap=1
Z4:	type=2
map_start=217598977 map_size=130 backup_map_start=217926525
next_map_start=217599107 next_map_size=34 next_backup_map_start=217926491
zone_first=217926656 zone_last=486544383 zone_size=268617728 min(chunk)=2048
free=122880 checksum=686e4921 logstamp=20936574 num_bitmap=19
Z5:	type=1
map_start=217599107 map_size=34 backup_map_start=217926491
next_map_start=486544385 next_map_size=33 next_backup_map_start=486546398
zone_first=217599141 zone_last=217926484 zone_size=327344 min(chunk)=8
free=249424 checksum=8a1089f2 logstamp=20936630 num_bitmap=17
Z6:	type=2
map_start=486544385 map_size=33 backup_map_start=486546398
next_map_start=1951669248 next_map_size=34 next_backup_map_start=1951671262
zone_first=486546432 zone_last=1951669247 zone_size=1465122816 min(chunk)=32768
free=101122048 checksum=a9c0de6e logstamp=20936594 num_bitmap=17
Z7:	type=2
map_start=1951669248 map_size=34 backup_map_start=1951671262
next_map_start=2928423937 next_map_size=66 next_backup_map_start=2928425917
zone_first=1951671296 zone_last=2928423935 zone_size=976752640 min(chunk)=20480
free=0 checksum=bfd5245 logstamp=20936568 num_bitmap=17
Z8:	type=2
map_start=2928423937 map_size=66 backup_map_start=2928425917
next_map_start=0 next_map_size=0 next_backup_map_start=3735928559
zone_first=2928425984 zone_last=3905174527 zone_size=976748544 min(chunk)=8192
free=976748544 checksum=16145d4 logstamp=20936568 num_bitmap=18

Partition Maps
#: type name length base ( size )
1 Apple_partition_map Apple [email protected] ( 31.5K)
2 Image Bootstrap 1 [email protected]( 512.0 )
3 Image Kernel 1 [email protected]( 4.0M)
4 Ext2 Root 1 [email protected]( 256.0M)
5 Image Bootstrap 2 [email protected]( 512.0 )
6 Image Kernel 2 [email protected]( 4.0M)
7 Ext2 Root 2 [email protected]( 256.0M)
8 Swap Linux swap [email protected]( 127.0M)
9 Ext2 /var [email protected]( 256.0M)
10 MFS MFS application region [email protected]( 288.0M)
11 MFS MFS media region [email protected] ( 231.7G)
12 MFS New MFS Application [email protected] ( 698.6G)
13 MFS MFS App by Winmfs [email protected]( 465.8G)
14 MFS New MFS Application [email protected]( 1.0M)
15 MFS New MFS Media [email protected]( 465.8G)
16 Apple_Free Extra [email protected]( 2.6M)

Total SA SD Hours: 2083	Total DTV SD Hours: 1818 28 % Free
Software: 11.0k-01-2-648	Tivo Model: TCD648250Bv


----------



## dougdingle (Jul 4, 2007)

And incidentally, I used a Seagate 2 TB NAS drive (it happened to be on sale), and am so far astonished at how cool and quiet it runs, even when doing a lot of seeking and writing.


----------



## ggieseke (May 30, 2008)

I'm running 5 Seagate 4TB drives in my Drobo, and I can't hear them.

On the WD/TiVo side, I haven't seen any real difference between Green drives, AV-rated drives, or the new Red drives. The specs are identical and so far they're all quiet and cool. I can still hear the PATA drives in my S2s on occasion, but not any of the newer drives.

When Comcast shows up next week to hook up my Roamio Pro I'm looking forward to an environment where my UPS is the noisiest box in the house.


----------



## dougdingle (Jul 4, 2007)

ggieseke said:


> On the WD/TiVo side, I haven't seen any real difference between Green drives, AV-rated drives, or the new Red drives.


I will say this: I've been copying a TON of bytes back and forth on SATA2 connections in this effort to merge two drives into one, and the WD Green drives are *half *the speed of the 7200 RPM drives in that use. Just dog slow. At first, I thought there was something wrong ;-).

I don't think it makes the slightest difference inside the TiVo, though.


----------



## dougdingle (Jul 4, 2007)

So I've run into an issue with the new setup. After downloading fresh guide data, it thinks it doesn't have any.

The guide does have about two weeks of program data visible.

There should be quite a bit of stuff in the ToDo List, but there's nothing. At the bottom of that screen is a notice which says there's no program info, and to connect to tivo for it. Looking at a Season's Pass' "See upcoming episodes" shows NO upcoming episodes, although there they are in the guide. And on the System Info screen, there's a line something like "Guide data current to:" and the field says "None available."

Any possibility that it's looking for it in some specific partition, and can't find it because we've moved stuff around?


----------



## dougdingle (Jul 4, 2007)

dougdingle said:


> So I've run into an issue with the new setup. After downloading fresh guide data, it thinks it doesn't have any.
> 
> The guide does have about two weeks of program data visible.
> 
> ...


So after three additional forced connections, everything is fine.

Had something to do with the indexing of the data - when it wasn't fine, despite the guide being fully populated, the info screen said the last index was from August.

Now it's current and it's all good.


----------

