lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 20 Mar 2017 13:22:20 +0300
From:   Благодаренко Артём 
        <artem.blagodarenko@...il.com>
To:     linux-ext4@...r.kernel.org
Cc:     Andreas Dilger <adilger@...ger.ca>,
        Alexey Lyashkov <alexey.lyashkov@...il.com>,
        Ts'o Theodore <tytso@....edu>
Subject: 64-bit inode number

Hello,

This topic was mentioned in "Add largedir feature”, but need to be discussed in separate thread.
Increasing maximum inode count is useful with and without larg_dir. There is at least one user who needs 64 bit inode number - Lustre FS. 

As mentioned, MDS has 0-size files to store some information about Lustre FS files. Current MDS disk sizes allow to store large amount of such files, but EXT4 limits this number to ~4 billions. 
Lustre FS has features like DNE to distribute MDS over many targets (disks), but disks are used  not effectively. It would be great to have ability to store more then  ~4 billions inodes on one
EXT4 file system.

 I know there is dirdata feature that allows to store higher 32 bit of inode number in ext4 dirent. As I know, direct was not merged yet because of user absence. Quote of Andreas from "Add largedir feature” 

> Mostly because there hasn't been any interest for it whenever I proposed
> merging it in the past. If there is some renewed interest in merging it
> I could look into it …

It looks like Lustre FS requires this feature now.

There is another approach how to solve this problem. It is obvious, but require change on disk format. Theodore’s quote from "Add largedir feature” 

> I can imagine a new feature flag which defines the use a 64-bit inode
> number, but that's more for people who are creating a file system that
> takes advantage of 64-bit block numbers, and they are intending on
> using all of that space to store small (< 4k or < 8k) files.


This is exact Lustre FS MDS example. Many small inodes. If it possible to add new feature flag, probably this is the best solution: simple, obvious, fast.

Please, help with this questions:
1. Do we need 64 bit number now? (My opinion - we need it)
2. What solution from two above to choose? Another solution?

Thanks.

Artem Blagodarenko



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ