This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 0/2] Squashing long inodes.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Denis Obrezkov <reprofy at etersoft dot ru>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org, Paul Eggert <eggert at cs dot ucla dot edu>
- Date: Wed, 5 Mar 2014 18:05:17 +0100
- Subject: Re: [PATCH 0/2] Squashing long inodes.
- Authentication-results: sourceware.org; auth=none
- References: <1393521776-1102-1-git-send-email-reprofy at etersoft dot ru> <53104E9A dot 3040706 at redhat dot com> <5310E3B9 dot 8000406 at redhat dot com> <80fd9464ba8db600f50871cb27f8d422 at office dot etersoft dot ru>
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.