Date:   Thu, 17 May 2018 20:45:51 +0300
From:   Alexey Lyashkov <alexey.lyashkov@...il.com>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     Artem Blagodarenko <artem.blagodarenko@...il.com>,
        Andreas Dilger <adilger@...ger.ca>,
        linux-ext4 <linux-ext4@...r.kernel.org>, adilger.kernel@...ger.ca
Subject: Re: [PATCH v4 5/7] ext2fs: Add helper functions to access inode
 numbers

Teo,

Some comments inside.
> 17 мая 2018 г., в 18:50, Theodore Y. Ts'o <tytso@....edu> написал(а):
> 
> 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.

Powered by blists - more mailing lists