On Fri, Feb 25, 2011 at 9:04 PM, Ted Ts'o <tytso@xxxxxxx> wrote: > On Fri, Feb 25, 2011 at 08:05:43PM +0200, Amir Goldstein wrote: >> >> I like your design. very KISS indeed. >> I am just wondering why should BIGALLOC be INCOMPAT and not RO_COMPAT? >> After all, ro mount doesn't allocate and RO_COMPAT features are so muc >> nicer... > > I can try to make it be RO_COMPAT, but one thing my design changes is > that a block group will contain 32768 allocation blocks; so assuming a > 4k blocks, instead of a block group containing a maximum of 32,768 4k > blocks comprising 128 MB, a block group would now contain 32,768 1M > blocks, or 32 GiB, or 8,388,608 4k blocks. > > I'm pretty sure that existing kernels have superblock sanity checks > that will barf if they see this. Still, yeah, I can try allocating > this as a ROCOMPAT feature, and later on, if people really care, they > can patch older kernels so they won't freak out when they see a > BigAlloc file system and can thus successfully mount it read-only. > > (Right now existing kernels will complain when s_blocks_per_group is > greater than blocksize*8.) > no problem. just rename s_blocks_per_group to s_bigblocks_per_group to be compatible with old kernels. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
