On Thu, 09 Dec 2010 17:10:28 +0530 Suresh Jayaraman <sjayaraman@xxxxxxx> wrote: > On 12/06/2010 09:08 PM, Jeff Layton wrote: > > On Mon, 06 Dec 2010 16:35:06 +0100 > > Bernhard Walle <bernhard@xxxxxxxxx> wrote: > > > >> > >> Zitat von Jeff Layton <jlayton@xxxxxxxxxx>: > >> > >>> > >>> I'm still not sure I like this patch however. It potentially means a > >>> lot of printk spam since these things have no ratelimiting. It also > >>> doesn't tell me anything about which server might be giving me grief. > >>> > >>> Maybe this should be turned into a cFYI? > >> > >> Well, if I see it in the kernel log, it doesn't matter if it's info or > >> something else. > >> > >>> The bottom line though is that running 32-bit applications that were > >>> built without -D_FILE_OFFSET_BITS=64 on a 64-bit kernel is a very bad > >>> idea. It would be nice to be able to alert users that things aren't > >>> working the way they expect, but I'm not sure this is the right place > >>> to do that. > >> > >> Well, but there *are* such application (in my case it was Softmaker Office > >> which is a proprietary word processor) and it's quite nice if you know > >> how you can workaround it when you encounter such a problem. That's all. > >> > > > > Sure...but this problem is not limited to CIFS. Many modern filesystems > > use 64-bit inodes. Running this application on XFS or NFS for instance > > is likely to give you the same trouble. You just hit it on CIFS because > > the server happened to give you a very large inode number. > > > > If we're going to add printk's for this situation, it probably ought to > > be in a more generic place. > > > > By generic place, did you mean at the VFS level? I think at VFS level, > there is little information about the Server or underlying fs and this > information doesn't seem too critical that VFS should warn/care much about. > > May be sticking to a cFYI along with Server detail is a good idea? > My poing was mainly that there's nothing special about CIFS in this regard, other than the fact that servers regularly send us inodes that are larger than 2^32. Why should we do this for cifs but not for nfs, xfs, ext4, etc? The filldir function gets a dentry as an argument, so it could reasonably generate a printk for this. I'm also not keen on the printk recommending noserverino for this. That has its own drawbacks. A cFYI for this sort of thing seems reasonable however. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
