Teo, Some comments inside. > 17 мая 2018 г., в 18:50, Theodore Y. Ts'o <tytso@xxxxxxx> написал(а): > > On Thu, May 17, 2018 at 01:55:53PM +0300, Artem Blagodarenko wrote: >> So I want to discuss some alternatives: >> >> 1) We could compile and link two lib versions: one with 32bit ext2_ino_t and another with 64bit. >> Pass some macross that says “ext2_ino_t” is *bit now. User can link both libraries >> (functions have same names, but different prototypes). I believe some extra cleanup is needed. >> There are some local variables and functions parameters which have type “bitness” hardcoded. >> But probably this less work then make both interface versions. >> >> 2) we could use LD Version Scripts >> https://www.gnu.org/software/gnulib/manual/html_node/LD-Version-Scripts.html >> This approach looks elegant, but still need more work to be done > > Using LD Version Scripts doesn't really help much in terms of the long > term maintainbilty of the source code, since you still have to > maintain two different function names in the library. Hm.. LD version script it not single way to point a symbol version. LD script can be very simple, but version have set in source code. like proposed in freebsd document (https://people.freebsd.org/~deischen/symver/freebsd_versioning.txt) .symver macro. But this way provide way to introduce any ABI changes and don’t worry about previously linked application. Yes, we will be need to maintain a two functions with names like $some_name$API_VER. But overal API will much clear as user don’t look what is functions with different ID at end and don’t need to have study about replacement in new version. > > The only other solution is to bite the bullet and just accept that we > have to do a major version number bump in the shared library. This > pushes the pain to the distributions, since they now have to rebuilt > all of the packages that depend on libext2fs. There aren't _that_ > many packages, but it does mean a certain of attention. > > > I think the other thing we really need to have a conversation about is > the cost/benefit ratio of 64-bit inode numbers in the first place. It > is going to be a huge amount of work, and it's going to have a pretty > large impact on the ext4 ecosystem. And I am worrying about about > what it does to the long term maintainability of the code --- > especially since so very few people will likely use the feature. > > Against that, I'm not sure I understand what the benefits are. It > seems to be mostly for Lustre, but I really don't understand why > Lustre can't more efficiently handle a large number of targets (file > systems). It’s not a question about Lustre itself, but about overall storage size. with 300T block device we have limited minimal file size with inode number count. 300T/4G - so just 75K per file is minimal chunk. But 300T isn’t limit for now it’s just 40 10T disks in RAID6. and 12T/14T disks coming son. Less size per RAID will increase overhead cost as more disks need to correct codes hold. > Using a single file system per disk makes it much easier to > balancing disk utilization. It also speeds up file system recovery > after a crash, since e2fsck can much more efficiently run in parallel > across each disk attached to a server. It also matches up the failure > domain caused by corrupted file system metadata with the failure > domain associated with HDD failure. > But using a single disk will reduce a overall system speed.
