_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Fri, 2007-08-03 at 15:07 -0400, Peter Staubach wrote:
> Hi.
>
> Attached is a patch to modify the NFS client code to support
> 64 bit ino's, as appropriate for the system and the NFS
> protocol version.
>
> The code basically just expand the NFS interfaces for routines
> which handle ino's from using ino_t to u64 and then uses the
> fileid in the nfs_inode instead of i_ino in the inode. The
> code paths that were updated are in the getattr method and
> the readdir methods.
>
> This should be no real change on 64 bit platforms. Since
> the ino_t is an unsigned long, it would already be 64 bits
> wide.
>
> Thanx...
>
> ps
Applied and queued for 2.6.24
Thanks Peter!
Trond
-------------------------------------------------------------------------
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
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Peter =C5strand wrote:
> On Fri, 3 Aug 2007, Peter Staubach wrote:
>
>> Attached is a patch to modify the NFS client code to support
>> 64 bit ino's, as appropriate for the system and the NFS
>> protocol version.
>>
>> The code basically just expand the NFS interfaces for routines
>> which handle ino's from using ino_t to u64 and then uses the
>> fileid in the nfs_inode instead of i_ino in the inode. The
>
> This patch seems to overlap with =
> linux-2.6-nfs-64-bit-inode-support.patch, 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.
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.
Thanx...
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
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 - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
T24gTW9uLCAyMDA3LTA4LTEzIGF0IDE2OjEyICswMjAwLCBQZXRlciDDhXN0cmFuZCB3cm90ZToK
Cj4gU3VyZSwgYnV0IHRvIHByZXZlbnQgY3VzdG9tZXIgdW5oYXBwaW5lc3MsIGl0J3MgbXVjaCBi
ZXR0ZXIgdG8gdXBkYXRlIHRoZSAKPiBhcHBsaWNhdGlvbnMgaW4gYSBjZXJ0YWluIGRpc3RyaWJ1
dGlvbiAqYmVmb3JlKiBjaGFuZ2luZyB0aGUgd29ybGQgYXJvdW5kIAo+IHRoZW0uIEknbSBhcmd1
aW5nIHRoYXQgYSB0eXBpY2FsIGN1c3RvbWVyIHdvdWxkIHJhdGhlciBiZWluZyBhYmxlIHRvIHJ1
biAKPiBPcGVuT2ZmaWNlIHRoYW4gbGl2ZSBpbiB0b21vcnJvd3Mgd29ybGQuCgo+IEFub3RoZXIg
cmVhc29uIHdoeSBJJ20gbm90IGNvbnZpbmNlZCBvZiB0aGlzIHBhdGNoIGlzIHRoYXQgSSBoYXZl
bid0IGhlYXJkIAo+IGFueSBhcmd1bWVudHMgd2h5IHRoaXMgaXMgdGhlIHRpbWUgdG8gYnJlYWsg
Y29tcGF0aWJpbGl0eSB3aXRoIAo+IDMyIGJpdCBub24tTEZTIGFwcHMuIFdoeSBub3QgdG9tb3Jy
b3csIHllc3RlcmRheSBvciAxMCB5ZWFycyBhZ28/IFdoeSBub3c/IAoKVGhpcyBhcmd1bWVudCBn
ZXRzIHRyb3R0ZWQgb3V0IGV2ZXJ5IGZyaWdnaW5nIHRpbWUgc29tZW9uZSBwcm9wb3NlcyBhCnBh
dGNoIG9mIHRoaXMgc29ydC4gMTIgbW9udGhzIGxhdGVyLCBhbm90aGVyIHBhdGNoIGNvbWVzIG91
dCwgYW5kIHdlCmRpc2NvdmVyIHRoYXQgdXNlcmxhbmQgaGFzbid0IGNoYW5nZWQuCgpXaHkgaGFz
bid0IGl0IGNoYW5nZWQ/CgpXZWxsLCBubyBjdXN0b21lcnMgd2VyZSBjb21wbGFpbmluZywgc28g
aXQgd2Fzbid0IG11Y2ggb2YgYSBwcmlvcml0eS4uLgoKQ2FuIHlvdSBzYXkgJ2NpcmN1bGFyIGFy
Z3VtZW50Jz8KClRyb25kCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpUaGlzIFNGLm5ldCBlbWFpbCBpcyBz
cG9uc29yZWQgYnk6IFNwbHVuayBJbmMuClN0aWxsIGdyZXBwaW5nIHRocm91Z2ggbG9nIGZpbGVz
IHRvIGZpbmQgcHJvYmxlbXM/ICBTdG9wLgpOb3cgU2VhcmNoIGxvZyBldmVudHMgYW5kIGNvbmZp
Z3VyYXRpb24gZmlsZXMgdXNpbmcgQUpBWCBhbmQgYSBicm93c2VyLgpEb3dubG9hZCB5b3VyIEZS
RUUgY29weSBvZiBTcGx1bmsgbm93ID4+ICBodHRwOi8vZ2V0LnNwbHVuay5jb20vCl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk5GUyBtYWlsbGlzdCAgLSAg
TkZTQGxpc3RzLnNvdXJjZWZvcmdlLm5ldApodHRwczovL2xpc3RzLnNvdXJjZWZvcmdlLm5ldC9s
aXN0cy9saXN0aW5mby9uZnMK