Re: [PATCH] 64 bit ino support for NFS client

[Peter Staubach <staubach@redhat.com>]

Peter =C5strand wrote:
> On Mon, 13 Aug 2007, Peter Staubach wrote:
>
>   =

>>> This patch seems to overlap with linux-2.6-nfs-64-bit-inode-support.pat=
ch,
>>> which is included in RHEL5 kernels. Are these patches related, somehow?=
 The
>>> RHEL5 patch causes problems, as described at
>>> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=3D241348. =

>>>       =

>> They are related in that they modify similar areas in the NFS code.
>> However, this patch only modifies the NFS code and not the rest of
>> the file systems and areas in the kernel.
>>
>> My opinion on the referenced bugzilla is that things change and
>> it may be time to update applications and such to work in the
>> new world.  Applications which do not get modified, tend to work
>> less and less as time goes by because while the world changes
>> around them, they don't.
>>     =

>
> Sure, but to prevent customer unhappiness, it's much better to update the =

> applications in a certain distribution *before* changing the world around =

> them. I'm arguing that a typical customer would rather being able to run =

> OpenOffice than live in tomorrows world.
>
>   =


Without issues to drive and even to identify the broken applications,
they will never get fixed.

> Another reason why I'm not convinced of this patch is that I haven't hear=
d =

> any arguments why this is the time to break compatibility with =

> 32 bit non-LFS apps. Why not tomorrow, yesterday or 10 years ago? Why now=
? =

>
>   =


We have to start someplace, sometime.  In fact, we've already
started.  It is unfortunate that this particular aspect is only
now starting to become visible to application developers.  It
has been interesting to file systems developers for quite some
time.

>   =

>> I don't believe that this is the only cause which will keep those
>> applications from working completely.  With the addition of the
>> LFS thing, they will start to encounter more and more things that
>> they are not prepared to deal with.
>>     =

>
> Can you give an example? =

>
>   =


Files with large sizes?  We've had these for what, 10 to 12
years, and people have learned to deal with them.

> If we maintain "good-enough compatibility" with 32 bit non-LFS =

> applications now (proposed solution 1 or 2 in comment #6), we would still =

> have full 64 bit support for LFS and 64 bit applications, and as LFS and =

> 64 bit applications are becoming more and more common, the problem would =

> fade away.

There are many ways to get "good-enough compatibility".  One way
would be for customers with concerns or issues to only use file
system implementations which will only generate 32 bit inos.  The
majority of them still do.  Alternately, they could partition
their resources into chunks which would not require more then
32 bit inos for identification.  It is only the newer file systems,
seeking to take advantage of better technologies, both hardware
and software, which are required to use larger identifiers in order
to identify their files.

Supporting 64 bit inos in NFS does not mean that NFS will
automatically start generating 64 bit inos.  NFS is still dependent
upon the file system on the server.  The NFS will just pass through
whatever that the file system on the server presents to it.

       ps

-------------------------------------------------------------------------
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  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs