_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Tue, 14 Aug 2007 09:58:41 +0200 (CEST)
Peter =C5strand <[email protected]> wrote:
> On Mon, 13 Aug 2007, Trond Myklebust wrote:
> =
> > > > If it isn't capable of dealing with the possibility of EOVERFLOW, t=
hen
> > > > it is violating the Single Unix Spec.
> > > =
> > > What can an app do, besides displaying a good error message? There's =
no =
> > > way to "deal" with EOVERFLOW that makes the user happy. =
> > =
> > So you are saying it should never have been defined in the first place?
> =
> No, it might be useful from time to time, on some systems. =
> =
> For example, the previous situation was that you got EOVERFLOW on 64 bit =
> kernels but truncated inode numbers on 32 bit kernels. I think this was a =
> fairly good compromise - customers had a choice. Typically, you select a =
> 32 bit kernel not because your hardware cannot do 64 bits, but because yo=
u =
> want maximum compatibility with old apps. So the approach with keep =
> truncating on 32 bit kernels made sense. =
> =
> Again, if would be even better if the behaviour could be selected runtime =
> or boot-time. A patch which simply changes this unconditionally is a =
> regression, IMHO.
> =
> =
> > > I can't see how a lack of LFS (of a binary) is a violation of SUS or =
> > > POSIX. Linux Standard Base requires that a platform provides LFS supp=
ort, =
> > > but it doesn't deprecate or forbid the non-LFS API functions.
> > =
> > If you are using the correct types, then recompiling with
> > -D_FILE_OFFSET_BITS=3D64 should be sufficient to enable LFS-compliant
> > behaviour. Portability was the reason for defining those types in the
> > first place.
> =
> You shouldn't be required to recompile. =
> =
> =
> > > Recompiling is almost never trivial. OpenOffice.org is just one examp=
le of =
> > > this. KDE is another. And sometimes the source is not available. =
> > =
> > Recompiling packages like OpenOffice.org is the bread-and-butter
> > business of Linux distributors.
> =
> Still, OO is not recompiled in RHEL5. =
> =
> In my opinion, it's also wrong to assume that all software running on a =
> certain system is compiled by the distribution maker. This is somewhat of =
> a Debian approach: all software should be included in the distribution, o=
r =
> may otherwise fail. Wrong, IMHO. =
> =
> =
> > > I still haven't understood what kind of functionality you are "sick a=
nd =
> > > tired of having to constantly postpone", that requires EOVERFLOW in 3=
2 bit =
> > > non-LFS land. =
> > =
> > The ability to supply the full 64-bit inode numbers to actual LFS
> > compliant applications.
> > LFS-aware backup apps, for instance, still cannot trust the inode number
> > to tell them whether or not two directory entries are actually hard
> > links to the same file. That would be pretty much the entire reason for
> > wanting to look at the st_ino variable in the first place.
> =
> LFS-aware applications running on 32 bit platforms needs to understand =
> that the world is not yet perfect. Even if 2.6.24 would stop truncating, =
> there are hundreds of earlier kernel versions in use, which will probably =
> still be in use for several more years from now. =
> =
> The backup application can take some extra care, for example, by verifyin=
g =
> st_size, st_mtime and perhaps a few bytes of the file as well. Not rocket =
> science. Probably done anyway, to detect if the file has been changed =
> during backup.
> =
> Still, I'm not opposing to enable full 64 bit inode numbers for LFS apps, =
> as long as non-LFS apps can still run. I'm no glibc expert, but as I =
> understand it, it *should* be possible to fix this in glibc. Have you =
> tried talking to the glibc developers about this? =
> =
A while back, I worked on a somewhat related patch to make sure that
the inode numbers generated by new_inode and iunique wouldn't generate
an EOVERFLOW in a non-LFS stat() call. My first proposal was to fix
this in glibc, but Jakub Jelenek disagreed with the approach. His
comments are here:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D213635#c16
comment #15 has a patch to affect this behavior based on an environment
var. I think you'll have a tough time convincing the glibc developers
that it's better to return a bogus st_ino rather than an error here.
Granted, NFS is a bit of a different situation, so maybe you'll have
better luck. =
-- =
Jeff Layton <[email protected]>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs