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...14#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
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.
(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
and the partition map for the external disk is
and MFSInfo for the combined pair gives
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:
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:
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
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
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:
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.
http://www.tivocommunity.com/tivo-vb...14#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
Code:
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=0x0When 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.
Code:
---------------------------------------------------------------------
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
---------------------------------------------------------------------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
Code:
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=0x0Code:
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=0x0Code:
---------------------------------------------------------------------
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
---------------------------------------------------------------------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:
Code:
hda10: 0 - 589823
hda11: 589824 - 217336831
hda12: 217336832 - 217926655
hda13: 217926656 - 486544383
hdc2: 486544384 - 486548479
hdc3: 486548480 - 2440069119
hda14: 2440069120 - 2440071167
hda15: 2440071168 - 3305179135I 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:
Code:
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(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
Code:
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=0x0When I run mfsinfo on it, I get
Code:
---------------------------------------------------------------------
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
---------------------------------------------------------------------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:
Code:
---------------------------------------------------------------------
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
---------------------------------------------------------------------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.
