Jeff Mahoney wrote: > Hi all - > > I recently posted about wanting to extend the maximum supported file > size from the 2 TB limit it currently has to the advertised maximum of 8 > TB. This turned out to be a flop since the file system format uses 512 > byte blocks in the stat data's sd_blocks field. So what do you want to keep in sd_blocks of 3.7 disks? > The format supports > larger file sizes in general, but this field is a stumbling block. Users > are trying to work within reiserfs's advertised limits and discovering > that the limits aren't as accurate as we thought. > > I commented during that thread about how I should have created a v3.7 > years ago when I first wrote the hack that is extended attributes. > > So, I have. See the following posts. The initial version doesn't have > any extended features - it just adds a new magic number and the feature > bitmasks to the superblock. It follows the ext[234] system of feature > bits to define which features are supported on the file system. > > I also have fsck support written but it is pretty untested still. Before > I invest more effort in this, I'd like to get a consensus of whether or > not this is desirable feature. > > My intention is that, once this is upstream, to backport it to our > earlier products to enable things like the 8 TB limit. > > The idea is to be able to convert an existing 3.6 file system to 3.7 , > just like the 3.5->3.6 conversion. You want to prohibit mounting of 3.6 disks to 3.7 kernels? I am afraid it will be a shock therapy: mandatory fsck can be rather painful for someone.. Edward. > For features like the blocksize > sd_blocks field, fsck --fix-fixable would adjust all the sd_blocks > values on the file system. > > -Jeff > -- To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
