[PATCH] 64 bit ino support for NFS client

[PATCH] 64 bit ino support for NFS client

[Peter Staubach]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

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

Signed-off-by: Peter Staubach <staubach@redhat.com>



[-- Attachment #2: fc-6.ino64.client --]
[-- Type: text/plain, Size: 3322 bytes --]

--- linux-2.6.22.i686/fs/nfs/dir.c.org
+++ linux-2.6.22.i686/fs/nfs/dir.c
@@ -407,7 +407,7 @@ int nfs_do_filldir(nfs_readdir_descripto
 	struct file	*file = desc->file;
 	struct nfs_entry *entry = desc->entry;
 	struct dentry	*dentry = NULL;
-	unsigned long	fileid;
+	u64		fileid;
 	int		loop_count = 0,
 			res;
 
@@ -418,7 +418,7 @@ int nfs_do_filldir(nfs_readdir_descripto
 		unsigned d_type = DT_UNKNOWN;
 		/* Note: entry->prev_cookie contains the cookie for
 		 *	 retrieving the current dirent on the server */
-		fileid = nfs_fileid_to_ino_t(entry->ino);
+		fileid = entry->ino;
 
 		/* Get a dentry if we have one */
 		if (dentry != NULL)
@@ -428,7 +428,7 @@ int nfs_do_filldir(nfs_readdir_descripto
 		/* Use readdirplus info */
 		if (dentry != NULL && dentry->d_inode != NULL) {
 			d_type = dt_type(dentry->d_inode);
-			fileid = dentry->d_inode->i_ino;
+			fileid = NFS_FILEID(dentry->d_inode);
 		}
 
 		res = filldir(dirent, entry->name, entry->len, 
@@ -1349,9 +1349,9 @@ static int nfs_rmdir(struct inode *dir, 
 static int nfs_sillyrename(struct inode *dir, struct dentry *dentry)
 {
 	static unsigned int sillycounter;
-	const int      i_inosize  = sizeof(dir->i_ino)*2;
+	const int      fileidsize  = sizeof(NFS_FILEID(dentry->d_inode))*2;
 	const int      countersize = sizeof(sillycounter)*2;
-	const int      slen       = sizeof(".nfs") + i_inosize + countersize - 1;
+	const int      slen        = sizeof(".nfs")+fileidsize+countersize-1;
 	char           silly[slen+1];
 	struct qstr    qsilly;
 	struct dentry *sdentry;
@@ -1369,8 +1369,9 @@ static int nfs_sillyrename(struct inode 
 	if (dentry->d_flags & DCACHE_NFSFS_RENAMED)
 		goto out;
 
-	sprintf(silly, ".nfs%*.*lx",
-		i_inosize, i_inosize, dentry->d_inode->i_ino);
+	sprintf(silly, ".nfs%*.*Lx",
+		fileidsize, fileidsize,
+		(unsigned long long)NFS_FILEID(dentry->d_inode));
 
 	/* Return delegation in anticipation of the rename */
 	nfs_inode_return_delegation(dentry->d_inode);
--- linux-2.6.22.i686/fs/nfs/inode.c.org
+++ linux-2.6.22.i686/fs/nfs/inode.c
@@ -450,8 +450,10 @@ int nfs_getattr(struct vfsmount *mnt, st
 		err = __nfs_revalidate_inode(NFS_SERVER(inode), inode);
 	else
 		err = nfs_revalidate_inode(NFS_SERVER(inode), inode);
-	if (!err)
+	if (!err) {
 		generic_fillattr(inode, stat);
+		stat->ino = NFS_FILEID(inode);
+	}
 	return err;
 }
 
--- linux-2.6.22.i686/fs/nfs/nfs4proc.c.org
+++ linux-2.6.22.i686/fs/nfs/nfs4proc.c
@@ -174,7 +174,7 @@ static void nfs4_setup_readdir(u64 cooki
 		*p++ = xdr_one;                         /* bitmap length */
 		*p++ = htonl(FATTR4_WORD0_FILEID);             /* bitmap */
 		*p++ = htonl(8);              /* attribute buffer length */
-		p = xdr_encode_hyper(p, dentry->d_inode->i_ino);
+		p = xdr_encode_hyper(p, NFS_FILEID(dentry->d_inode));
 	}
 	
 	*p++ = xdr_one;                                  /* next */
@@ -186,7 +186,7 @@ static void nfs4_setup_readdir(u64 cooki
 	*p++ = xdr_one;                         /* bitmap length */
 	*p++ = htonl(FATTR4_WORD0_FILEID);             /* bitmap */
 	*p++ = htonl(8);              /* attribute buffer length */
-	p = xdr_encode_hyper(p, dentry->d_parent->d_inode->i_ino);
+	p = xdr_encode_hyper(p, NFS_FILEID(dentry->d_parent->d_inode));
 
 	readdir->pgbase = (char *)p - (char *)start;
 	readdir->count -= readdir->pgbase;

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Trond Myklebust]

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

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

[Peter Åstrand]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 805 bytes --]

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=241348.

Regards, 
---
Peter Ã…strand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.se
Wallenbergs gata 4
583 30 Linköping	Phone: +46-13-21 46 00

[-- Attachment #2: Type: TEXT/PLAIN, Size: 3322 bytes --]

--- linux-2.6.22.i686/fs/nfs/dir.c.org
+++ linux-2.6.22.i686/fs/nfs/dir.c
@@ -407,7 +407,7 @@ int nfs_do_filldir(nfs_readdir_descripto
 	struct file	*file = desc->file;
 	struct nfs_entry *entry = desc->entry;
 	struct dentry	*dentry = NULL;
-	unsigned long	fileid;
+	u64		fileid;
 	int		loop_count = 0,
 			res;
 
@@ -418,7 +418,7 @@ int nfs_do_filldir(nfs_readdir_descripto
 		unsigned d_type = DT_UNKNOWN;
 		/* Note: entry->prev_cookie contains the cookie for
 		 *	 retrieving the current dirent on the server */
-		fileid = nfs_fileid_to_ino_t(entry->ino);
+		fileid = entry->ino;
 
 		/* Get a dentry if we have one */
 		if (dentry != NULL)
@@ -428,7 +428,7 @@ int nfs_do_filldir(nfs_readdir_descripto
 		/* Use readdirplus info */
 		if (dentry != NULL && dentry->d_inode != NULL) {
 			d_type = dt_type(dentry->d_inode);
-			fileid = dentry->d_inode->i_ino;
+			fileid = NFS_FILEID(dentry->d_inode);
 		}
 
 		res = filldir(dirent, entry->name, entry->len, 
@@ -1349,9 +1349,9 @@ static int nfs_rmdir(struct inode *dir, 
 static int nfs_sillyrename(struct inode *dir, struct dentry *dentry)
 {
 	static unsigned int sillycounter;
-	const int      i_inosize  = sizeof(dir->i_ino)*2;
+	const int      fileidsize  = sizeof(NFS_FILEID(dentry->d_inode))*2;
 	const int      countersize = sizeof(sillycounter)*2;
-	const int      slen       = sizeof(".nfs") + i_inosize + countersize - 1;
+	const int      slen        = sizeof(".nfs")+fileidsize+countersize-1;
 	char           silly[slen+1];
 	struct qstr    qsilly;
 	struct dentry *sdentry;
@@ -1369,8 +1369,9 @@ static int nfs_sillyrename(struct inode 
 	if (dentry->d_flags & DCACHE_NFSFS_RENAMED)
 		goto out;
 
-	sprintf(silly, ".nfs%*.*lx",
-		i_inosize, i_inosize, dentry->d_inode->i_ino);
+	sprintf(silly, ".nfs%*.*Lx",
+		fileidsize, fileidsize,
+		(unsigned long long)NFS_FILEID(dentry->d_inode));
 
 	/* Return delegation in anticipation of the rename */
 	nfs_inode_return_delegation(dentry->d_inode);
--- linux-2.6.22.i686/fs/nfs/inode.c.org
+++ linux-2.6.22.i686/fs/nfs/inode.c
@@ -450,8 +450,10 @@ int nfs_getattr(struct vfsmount *mnt, st
 		err = __nfs_revalidate_inode(NFS_SERVER(inode), inode);
 	else
 		err = nfs_revalidate_inode(NFS_SERVER(inode), inode);
-	if (!err)
+	if (!err) {
 		generic_fillattr(inode, stat);
+		stat->ino = NFS_FILEID(inode);
+	}
 	return err;
 }
 
--- linux-2.6.22.i686/fs/nfs/nfs4proc.c.org
+++ linux-2.6.22.i686/fs/nfs/nfs4proc.c
@@ -174,7 +174,7 @@ static void nfs4_setup_readdir(u64 cooki
 		*p++ = xdr_one;                         /* bitmap length */
 		*p++ = htonl(FATTR4_WORD0_FILEID);             /* bitmap */
 		*p++ = htonl(8);              /* attribute buffer length */
-		p = xdr_encode_hyper(p, dentry->d_inode->i_ino);
+		p = xdr_encode_hyper(p, NFS_FILEID(dentry->d_inode));
 	}
 	
 	*p++ = xdr_one;                                  /* next */
@@ -186,7 +186,7 @@ static void nfs4_setup_readdir(u64 cooki
 	*p++ = xdr_one;                         /* bitmap length */
 	*p++ = htonl(FATTR4_WORD0_FILEID);             /* bitmap */
 	*p++ = htonl(8);              /* attribute buffer length */
-	p = xdr_encode_hyper(p, dentry->d_parent->d_inode->i_ino);
+	p = xdr_encode_hyper(p, NFS_FILEID(dentry->d_parent->d_inode));
 
 	readdir->pgbase = (char *)p - (char *)start;
 	readdir->count -= readdir->pgbase;

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #4: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Peter Staubach]

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

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

[Peter Åstrand]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2040 bytes --]

On Mon, 13 Aug 2007, Peter Staubach wrote:

> > 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=241348. 
> 
> 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.

Another reason why I'm not convinced of this patch is that I haven't heard 
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? 


> 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? 

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.


Regards, 
---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.se
Wallenbergs gata 4
583 30 Linköping	Phone: +46-13-21 46 00

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Peter Staubach]

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

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

[Peter Åstrand]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3461 bytes --]

On Mon, 13 Aug 2007, Peter Staubach wrote:

> > 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.

I agree, it was good that the kernel patch was tried and the problems 
identified. However, now that we know that the patch causes problems and 
no fix for either KDE or OpenOffice are in sight, the patch should be 
pulled out, IMHO. 

Compatibility with legacy third party application is another reason, that 
we haven't even touched yet. 


> > Another reason why I'm not convinced of this patch is that I haven't heard
> > 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.

Application developers (or perhaps, binary builders) will probably migrate 
to LFS or 64 bit anyway, to gain support for large files etc. 

The patch that breaks compat with 32 bit non-LFS can be tried internally, 
or during testing, to identify apps with problems. Then we can file bug 
reports to the individual projects. But breaking apps now and then just 
hope that someone will fix them someday in the future is the wrong 
approach, IMHO.


> 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.

Not necessarily true, or do you only care about Linux clients and Linux 
servers? In that case, we can just as well rename our NFS support to 
something like "Linux Ext3 Network File System"... 

There's nothing in the NFSv3 specification that requires you to directly 
map inode numbers to fileid. NFS is supposed to be cross platform. If the 
NFS client requires that fileids are constructed in a certain way, we can 
just as well rely on certain Linux-specific bit fields in the file 
handles. 

But we don't want to do that, we want a client that works with as many NFS 
servers as possible, as long as they are adhering to RFC1813. We can do 
this and at the same time support 32 bit non-LFS applications, this has 
worked fine for many years now. Sure, in very rare cases you will have a 
problem, but your cure is worse than the disease. 

Or, as Dave Noveck puts it at 
http://www1.ietf.org/mail-archive/web/nfsv4/current/msg01590.html:

"As a user my feeling is that it is better to compromise on fileid 
uniqueness when dealing with 32-bit applications, and give the user 
something that has some possibility of conflict as opposed to an error 
which stops him cold.  Most applications that do stat don't care about 
fileid uniqueness."

Regards, 
---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.se
Wallenbergs gata 4
583 30 Linköping	Phone: +46-13-21 46 00

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Trond Myklebust]

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

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

[Peter Åstrand]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1203 bytes --]

On Mon, 13 Aug 2007, Trond Myklebust wrote:

>> Well, no customers were complaining, so it wasn't much of a priority...
>> 
>> Can you say 'circular argument'?
>Could we add a CONFIG option to enable regressive distributions to turn
>this feature off? 

It would be much more useful with a glibc runtime configuration. 


>I'm sick and tired of having to constantly postpone necessary 
>functionality just because application writers aren't capable of coding 
>up standards compliant programs.

I don't understand this logic. What kind of standard is a 32 bit non-LFS 
app breaking?

What kind of functionality are you thinking of? 100% guaranteed unique 
inode numbers, assuming that all fileids are unique? You already have that 
on 64 bit systems, and as far as I understand, it should be possible to 
get this for LFS-aware 32 bit apps as well. 

Or are you referring to 100% guaranteed unique inode numbers for 32 bit 
apps, LFS aware or not? Why is this important?

Or are you thinking of some other functionality?


Regards, 
---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.se
Wallenbergs gata 4
583 30 Linköping	Phone: +46-13-21 46 00

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Trond Myklebust]

T24gTW9uLCAyMDA3LTA4LTEzIGF0IDE4OjQ2ICswMjAwLCBQZXRlciDDhXN0cmFuZCB3cm90ZToK
PiBPbiBNb24sIDEzIEF1ZyAyMDA3LCBUcm9uZCBNeWtsZWJ1c3Qgd3JvdGU6Cj4gCj4gPj4gV2Vs
bCwgbm8gY3VzdG9tZXJzIHdlcmUgY29tcGxhaW5pbmcsIHNvIGl0IHdhc24ndCBtdWNoIG9mIGEg
cHJpb3JpdHkuLi4KPiA+PiAKPiA+PiBDYW4geW91IHNheSAnY2lyY3VsYXIgYXJndW1lbnQnPwo+
ID5Db3VsZCB3ZSBhZGQgYSBDT05GSUcgb3B0aW9uIHRvIGVuYWJsZSByZWdyZXNzaXZlIGRpc3Ry
aWJ1dGlvbnMgdG8gdHVybgo+ID50aGlzIGZlYXR1cmUgb2ZmPyAKPiAKPiBJdCB3b3VsZCBiZSBt
dWNoIG1vcmUgdXNlZnVsIHdpdGggYSBnbGliYyBydW50aW1lIGNvbmZpZ3VyYXRpb24uIAoKUG9z
c2libHkuCgo+ID5JJ20gc2ljayBhbmQgdGlyZWQgb2YgaGF2aW5nIHRvIGNvbnN0YW50bHkgcG9z
dHBvbmUgbmVjZXNzYXJ5IAo+ID5mdW5jdGlvbmFsaXR5IGp1c3QgYmVjYXVzZSBhcHBsaWNhdGlv
biB3cml0ZXJzIGFyZW4ndCBjYXBhYmxlIG9mIGNvZGluZyAKPiA+dXAgc3RhbmRhcmRzIGNvbXBs
aWFudCBwcm9ncmFtcy4KPiAKPiBJIGRvbid0IHVuZGVyc3RhbmQgdGhpcyBsb2dpYy4gV2hhdCBr
aW5kIG9mIHN0YW5kYXJkIGlzIGEgMzIgYml0IG5vbi1MRlMgCj4gYXBwIGJyZWFraW5nPwoKSWYg
aXQgaXNuJ3QgY2FwYWJsZSBvZiBkZWFsaW5nIHdpdGggdGhlIHBvc3NpYmlsaXR5IG9mIEVPVkVS
RkxPVywgdGhlbgppdCBpcyB2aW9sYXRpbmcgdGhlIFNpbmdsZSBVbml4IFNwZWMuCgpJZiBpdCBp
cyBtYWtpbmcgYXNzdW1wdGlvbnMgYWJvdXQgdGhlIHNpemUgb2Ygc3RfaW5vLCB0aGVuIGl0IGlz
CnZpb2xhdGluZyBub3Qgb25seSBTVVMsIGJ1dCBhbHNvIFBPU0lYLCB3aGljaCBkb2VzIG5vdyBt
YW5kYXRlIHRoZSB1c2UKb2YgdGhlIHNwZWNpZmljIHR5cGVzOgoKICBodHRwOi8vd3d3Lm9wZW5n
cm91cC5vcmcvb25saW5lcHVicy8wMDk2OTUzOTkvdG9jLmh0bQoKPiBXaGF0IGtpbmQgb2YgZnVu
Y3Rpb25hbGl0eSBhcmUgeW91IHRoaW5raW5nIG9mPyAxMDAlIGd1YXJhbnRlZWQgdW5pcXVlIAo+
IGlub2RlIG51bWJlcnMsIGFzc3VtaW5nIHRoYXQgYWxsIGZpbGVpZHMgYXJlIHVuaXF1ZT8gWW91
IGFscmVhZHkgaGF2ZSB0aGF0IAo+IG9uIDY0IGJpdCBzeXN0ZW1zLCBhbmQgYXMgZmFyIGFzIEkg
dW5kZXJzdGFuZCwgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIAo+IGdldCB0aGlzIGZvciBMRlMt
YXdhcmUgMzIgYml0IGFwcHMgYXMgd2VsbC4gCj4gCj4gT3IgYXJlIHlvdSByZWZlcnJpbmcgdG8g
MTAwJSBndWFyYW50ZWVkIHVuaXF1ZSBpbm9kZSBudW1iZXJzIGZvciAzMiBiaXQgCj4gYXBwcywg
TEZTIGF3YXJlIG9yIG5vdD8gV2h5IGlzIHRoaXMgaW1wb3J0YW50Pwo+IAo+IE9yIGFyZSB5b3Ug
dGhpbmtpbmcgb2Ygc29tZSBvdGhlciBmdW5jdGlvbmFsaXR5PwoKSWYgdGhlIHByb2dyYW0gaXMg
d3JpdHRlbiBpbiBhIG1hbm5lciB0aGF0IGlzIFBPU0lYIGNvbXBsaWFudCAoaS5lLiB1c2VzCnRo
ZSBjb3JyZWN0IHR5cGVzKSB0aGVuIHJlY29tcGlsaW5nIGZvciBhIDY0LWJpdCBMRlMgZW52aXJv
bm1lbnQgaXMKdHJpdmlhbC4KClRyb25kCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpUaGlzIFNGLm5ldCBl
bWFpbCBpcyBzcG9uc29yZWQgYnk6IFNwbHVuayBJbmMuClN0aWxsIGdyZXBwaW5nIHRocm91Z2gg
bG9nIGZpbGVzIHRvIGZpbmQgcHJvYmxlbXM/ICBTdG9wLgpOb3cgU2VhcmNoIGxvZyBldmVudHMg
YW5kIGNvbmZpZ3VyYXRpb24gZmlsZXMgdXNpbmcgQUpBWCBhbmQgYSBicm93c2VyLgpEb3dubG9h
ZCB5b3VyIEZSRUUgY29weSBvZiBTcGx1bmsgbm93ID4+ICBodHRwOi8vZ2V0LnNwbHVuay5jb20v
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCk5GUyBtYWls
bGlzdCAgLSAgTkZTQGxpc3RzLnNvdXJjZWZvcmdlLm5ldApodHRwczovL2xpc3RzLnNvdXJjZWZv
cmdlLm5ldC9saXN0cy9saXN0aW5mby9uZnMK

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

[Peter Åstrand]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2388 bytes --]

On Mon, 13 Aug 2007, Trond Myklebust wrote:

> > >functionality just because application writers aren't capable of coding 
> > >up standards compliant programs.
> > 
> > I don't understand this logic. What kind of standard is a 32 bit non-LFS 
> > app breaking?
> 
> If it isn't capable of dealing with the possibility of EOVERFLOW, then
> 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. 


> If it is making assumptions about the size of st_ino, then it is
> violating not only SUS, but also POSIX, which does now mandate the use
> of the specific types:
> 
>   http://www.opengroup.org/onlinepubs/009695399/toc.htm

Even if the application is using specific types and takes care not to make 
assumptions about sizes, EOVERFLOW can occur. It can happen either because 
it's not built with LFS on platforms where LFS is not default (right?), or 
because it was built on another system, perhaps lacking LFS entirely. 

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 support, 
but it doesn't deprecate or forbid the non-LFS API functions.


> > What kind of functionality are you thinking of? 100% guaranteed unique 
> > inode numbers, assuming that all fileids are unique? You already have that 
> > on 64 bit systems, and as far as I understand, it should be possible to 
> > get this for LFS-aware 32 bit apps as well. 
> > 
> > Or are you referring to 100% guaranteed unique inode numbers for 32 bit 
> > apps, LFS aware or not? Why is this important?
> > 
> > Or are you thinking of some other functionality?
> 
> If the program is written in a manner that is POSIX compliant (i.e. uses
> the correct types) then recompiling for a 64-bit LFS environment is
> trivial.

Recompiling is almost never trivial. OpenOffice.org is just one example of 
this. KDE is another. And sometimes the source is not available. 

I still haven't understood what kind of functionality you are "sick and 
tired of having to constantly postpone", that requires EOVERFLOW in 32 bit 
non-LFS land. 

Rgds, 
---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.se
Wallenbergs gata 4
583 30 Linköping	Phone: +46-13-21 46 00

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Peter Åstrand]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3915 bytes --]

On Mon, 13 Aug 2007, Trond Myklebust wrote:

> > > If it isn't capable of dealing with the possibility of EOVERFLOW, then
> > > 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 you 
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 support, 
> > 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=64 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 example 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, or 
may otherwise fail. Wrong, IMHO. 


> > I still haven't understood what kind of functionality you are "sick and 
> > tired of having to constantly postpone", that requires EOVERFLOW in 32 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 verifying 
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? 

Another idea is a runtime kernel configuration option, say either booting 
with a command line option. This solution could be useful even if future 
glibc versions solves this issue, to work around the problem on systems 
with old/current versions of glibc. What do you think of this?


Regards, 
---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.se
Wallenbergs gata 4
583 30 Linköping	Phone: +46-13-21 46 00

[-- Attachment #2: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

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

[Jeff Layton]

On Tue, 14 Aug 2007 09:58:41 +0200 (CEST)
Peter =C5strand <astrand@cendio.se> 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 <jlayton@redhat.com>

-------------------------------------------------------------------------
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