64 bit ino support for NFS client

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

@@ -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);

@@ -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;
 }
 

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

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

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

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

@@ -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);

@@ -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;
 }
 

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

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

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

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?

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

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

ch,

The

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

d =

? =

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.

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

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

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.

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.

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

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

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

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

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

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

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

What can an app do, besides displaying a good error message? There's no way to "deal" with EOVERFLOW that makes the user happy.

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.

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

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

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.

You shouldn't be required to recompile.

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.

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

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

hen

no =

u =

ort, =

le of =

r =

nd =

2 bit =

g =

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