Re: [RFC] reiserfs 3.7

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Hash: SHA1

On 11/21/2010 06:49 AM, Edward Shishkin wrote:
> 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?

It would be kept in file system blocksize blocks.

>> 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..

No, that's not the idea at all. The idea is that 3.7 would be a superset
of the 3.6 implementation. Anything else would create a flag day in
which your file system is totally dependent on which version of the
kernel you're running, even if you didn't take any action to change
anything. That's obviously completely unacceptable. Kernels with 3.7
support will be able to mount versions <= 3.7. Kernels with 3.6 support
would be able to mount versions <= 3.6(jr).

On a system without any 3.7 features enabled, it should also be possible
to revert back to 3.6 if desired. We actually have this ability vs the
3.5->3.6 conversion because the feature bits indicate which features
beyond those offered in 3.6 are in use. The code to back out feature
bits hasn't been implemented yet as I expect only a small subset of
users would ever want that functionality.

- -Jeff

>> 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

- -- 
Jeff Mahoney
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with SUSE -

To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Index of Archives]     [Linux BTRFS]     [Linux NFS]     [Linux Filesystems]     [Ext4 Filesystem]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Photo]     [Yosemite Forum]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux