On 01/26/2011 02:53 AM, Li Zefan wrote: > Here comes the compatability issue. It's fine to mount old btrfs, because > we'll just use the original way to find free ino. But we can't mount new btrfs > in older kernels, because the OFFSET makes highest objectid overflow when it > is cast to unsigned long in 32bits system. > > We can store ino extents to a seperate btree, and then the new btrfs can > be mounted in older kernels, but another problem will arise when remounting it > in new kernels - creating new files will probably fail (but not oops) > because the ino extent items are not consistent with inode items. > > If the above behavior (failing to create files) is not acceptable, we'll > have to add an incompat flag.
I can't comment the patch from a technical point of view. However I want to add a my comment about the compatibility issues. I remember that Linus was not happy about a filesystem which is not compatible when the the kernel version decrease. IIRC during the switch from ext3 to ext4 there were some issues during a git bis-sect process. So my suggestions are: - don't allow that an automatic switch to the new inode allocation policy. It should be the user to force this switch ( via a mount option for example) - in case the performance regression are noticeable, allow the user to use the old policy, which, if I understood correctly, work fine on a 64 bit system [*]. Regards G.Baroncelli [*] Supposing to create continuously 1000 file per sec, it needs 2^64/1000 sec = ~ 573.000.000 years to exhaust all the available inode numbers. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
