Page 2 of 2 FirstFirst 12
Results 16 to 22 of 22

Thread: Maximum partition number, I thought it was 16 but...

  1. #16
    Join Date
    May 2004
    Posts
    253
    Quote Originally Posted by Jamie View Post
    There's a maximum partition size of 1TiB with a stock tivo kernel
    If I understand correctly, WinMFS can put 2 traditional MFS partitions into one ("You can pack the zonemap info and the zone itself all into one partition, and tivo likes it just fine."). If that's not what they're doing, they're at least doing something to allow an existing partition to grow - so why not grow the last existing partition to 1 TiB before adding another?

    If there's a limit of 6 (or 8) MFS partitions on a single drive, shouldn't that allow way more than enough room? (you run into the 2GiB Apple Partition Map limit first).
    problems if you try to expand a stock image
    A stock image has at least 2 partitions available for expansion, right? Why can't each be <1TiB? It's just a matter of having tools which know what to do.

    At this point in time, when we're bumping against the 2 TiB limit, to me it makes more sense for TiVo to move to GPT, and up the number of supported MFS partitions. That provides a long term solution. (To paraphrase billg: Surely 18446744073709551616 blocks are enough for anyone.)

  2. #17
    Join Date
    Aug 2004
    Posts
    4,075
    Quote Originally Posted by mike_s View Post
    If I understand correctly, WinMFS can put 2 traditional MFS partitions into one ("You can pack the zonemap info and the zone itself all into one partition, and tivo likes it just fine."). If that's not what they're doing, they're at least doing something to allow an existing partition to grow - so why not grow the last existing partition to 1 TiB before adding another?

    If there's a limit of 6 (or 8) MFS partitions on a single drive, shouldn't that allow way more than enough room? (you run into the 2GiB Apple Partition Map limit first).A stock image has at least 2 partitions available for expansion, right? Why can't each be <1TiB? It's just a matter of having tools which know what to do.
    You'd have to ask Spike2K what WinMFS can and can't do. Yes, there are multiple ways to work around this problem, but few are compatable with existing tools (winmfs and mfstools).

    If you'd like to lobby against my proposed changes, express your opinion in the TCF thread.
    At this point in time, when we're bumping against the 2 TiB limit, to me it makes more sense for TiVo to move to GPT, and up the number of supported MFS partitions. That provides a long term solution. (To paraphrase billg: Surely 18446744073709551616 blocks are enough for anyone.)
    Agreed, TiVo should replace the Apple Partition Map. On existing hardware, that would likely mean field reflashing all of our PROM's, since the PROM code has to grok the parititon map to find the boot kernel. It seems unlike they will want to do this. Too much risk of bricking tivos in the field, and letting out methods for in-place reflashing could open up new hacking possibilities they might rather keep to themselves.

    I would expect a new partition map format in the next hw release, but I'm just guessing.

  3. #18
    Join Date
    May 2004
    Posts
    253
    Quote Originally Posted by Jamie View Post
    If you'd like to lobby against my proposed changes, express your opinion in the TCF thread.
    I'm not opposed, I just think TiVo's development time is better spent elsewhere.
    On existing hardware, that would likely mean field reflashing all of our PROM's, since the PROM code has to grok the parititon map to find the boot kernel.
    GPT has a "fake" MBR, which can be used to create a hybrid MBR/GPT partition table. That can be used to allow the boot PROM to find the kernel and kick it off, at which point the real GPT would be used. Such use violates the formal EFI/GPT specs, but that wouldn't matter on an embedded system. Apple has used just such a hybrid partition table to support their Bootcamp dual boot capability. The issues involved revolve around keeping the two partition tables in sync if/when a change is made.

    Problem is, TiVo has little impetus to implement this in software for current units, since from their perspective, those TiVos are of static configuration.

  4. #19
    Join Date
    Aug 2004
    Posts
    4,075
    OK. I don't know a lot about GPT. Can the "fake MBR" be the tivo style APM MBR, i.e. 64 blocks? Or is it hardwired to the old fdisk/msdos style partition map?

    My suggestions are intended to be quick and easy things they could do to allow expansion onto larger disk on existing tivo platforms without a major overhaul. I certainly believe, as you do, that longer term "full" solutions should not be ignored either. But if an hour or two of tivo engineering time could allow current customers to expand onto the newer larger disks, it seems like there might be some value there.

  5. #20
    Join Date
    May 2004
    Posts
    253
    Quote Originally Posted by Jamie View Post
    OK. I don't know a lot about GPT. Can the "fake MBR" be the tivo style APM MBR...
    Doh. You're right, I was confusing partition table types. GPT can hybrid with MBR (i.e. MS-DOS), but not with an Apple Partition Map (APM). I wonder if the ROM understands MBR (it's relatively simple to distinguish between MBT and APM), or if it calls code in block 0 (there's something at 0x0A4 which isn't an ASCII string: 0A E8 E1 80 8F 9D 03 B0 0B E8 3C).

  6. #21
    Join Date
    Jul 2005
    Posts
    504
    Quote Originally Posted by mike_s View Post
    At this point in time, when we're bumping against the 2 TiB limit, to me it makes more sense for TiVo to move to GPT, and up the number of supported MFS partitions. That provides a long term solution. (To paraphrase billg: Surely 18446744073709551616 blocks are enough for anyone.)
    Does GPT also use 32 bit addressing? I know GPT can use 4096 byte sectors (possibly higher) and APM assumes 512 only. It should be possible to use an APM with larger than 512 blocks which would increase the 2tb limit per drive.

    Check this http://rentzsch.com/tidbits/intelbas...ncompatibility
    Quote Originally Posted by website
    I’m surprised this “new” scheme doesn’t use 48- or 64-bit sector addressing. In fact, APM supports volumes larger than 2TB, although you have to increase the sector size (both schemes use 32-bit sector addressing, however GPT assumes a 512 sector size while APM specifies it).
    He may be wrong about 32 bits, and I think he meant blocks in that quote, but either way if I have some free time and can find an extra drive I will try larger than 512 bytes.

    Quote Originally Posted by mike_s View Post
    so why not grow the last existing partition to 1 TiB before adding another? If there's a limit of 6 (or 8) MFS partitions on a single drive, shouldn't that allow way more than enough room? (you run into the 2GiB Apple Partition Map limit first).A stock image has at least 2 partitions available for expansion, right? Why can't each be <1TiB? It's just a matter of having tools which know what to do.
    Good question. The tools should have an option to create a 1tb partition maximum and then fill the remaining space with another partition.

    I thought the MFS partition limit was per system and not per drive, as in 8 overall no matter where they exist.


    Quote Originally Posted by mike_s View Post
    An upgrade doesn't change the partitioning, it just formats (mkfs) the "other" root partition before populating it?
    That's why the /dev/hdc17 and greater will die - they don't exist when the other root is booted.
    Last edited by ciper; 02-13-2009 at 09:21 PM.

  7. #22
    Join Date
    May 2004
    Posts
    253
    Quote Originally Posted by ciper View Post
    Does GPT also use 32 bit addressing? I know GPT can use 4096 byte sectors (possibly higher) and APM assumes 512 only. It should be possible to use an APM with larger than 512 blocks which would increase the 2tb limit per drive.
    GPT uses 64 bit addressing. Just to be clear here, we're discussing hard disc logical blocks, not filesystem blocks. Partition tables refer to logical blocks. Using a different block size requires support from the drive manufacturer. If the APM says kernel partition x starts at block y, that's where the boot ROM is going to run code from. The ROM justs asks the drive for blocks starting at y.

    512 byte sector size has been "standard" for a long time. The 2 TB WD20EADS drive still uses that size.

    Maybe when the next generation of >2TiB drives comes out, we'll see larger block sizes on the drives.
    I thought the MFS partition limit was per system and not per drive, as in 8 overall no matter where they exist.
    The MFS limit is 12. The TiVo partitioning scheme uses 2x(bootstrap, kernel, root)+var+swap+APM=9 partitions for the OS, leaving 7 for MFS. TiVO sets up MFS partitions in zonemap/zone pairs, so 6 is the max on a boot disc.

    One could make use of the unused "bootstrap" partitions on a single boot drive and be able to fit 8 MFS partitions on that drive. I assume that's what we're talking about, since for 2 drive systems, there are plenty of partitions available on the second drive for MFS.
    That's why the /dev/hdc17 and greater will die - they don't exist when the other root is booted.
    Not an issue on a hacked TiVo, adding the dev nodes would just become a part of rehacking during an upgrade.
    Last edited by mike_s; 02-14-2009 at 11:54 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •