Re: [PATCH 0/2] Squashing long inodes.

[OndÅej BÃlka <neleai at seznam dot cz>]

On Wed, Mar 05, 2014 at 05:32:23PM +0400, Denis Obrezkov wrote:
> I understand that glibc has its own global purposes and its own view
> on the problem. Let me introduce user's view.
> First of all, I completely agree that programs should be compiled
> with _FILE_OFFSET_BITS defined to 64. Also I believe that one day all
> programs will use only proper structures for proper aims.
> But unfortunately today isn't this day, probably tomorrow isn't too.
> Thus we have some legacy programs which couldn't be recompiled at all
> and programs which couldn't be recompiled with this flag due to their
> nature(mixing 32bit and 64bit things will cause undefined behavior).
> And these programs aren't work because hundreds of packages and
> libraries
> use stat only to make sure themselves that needed file exists. They
> fail
> every time when they want to checkout file's existence. I think it's
> more serious bug than all the bugs which may be caused by squashing.
> Also in this case(changing somehow inodes) we could take care of users
> by outputting some kind of dmesg that squashing s used. So the
> question is:
> could you tell me what is the better way - squash or zeroing?
> Even if we wouldn't do something with inode in glibc, we, simple users,
> have to make our programs work.

A problem is that we cannot introduce a unreliable solution as default.


It could be enabled by a environment variable but also as indepent
library.

Creating library that does this by overriding stat functions preferably
by using hash table and giving 32bit inode numbers sequentialy has
advantage that you do not have to ask anybody for permission.

Of course hard part is to make people use it.