From: Suresh Jayaraman <sjayaraman@suse.de>
To: Jeff Layton <jlayton@redhat.com>
Cc: Bernhard Walle <bernhard@bwalle.de>,
sfrench@samba.org, linux-cifs@vger.kernel.org,
samba-technical@lists.samba.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cifs: Add information about noserverino
Date: Thu, 09 Dec 2010 17:10:28 +0530 [thread overview]
Message-ID: <4D00C02C.4070006@suse.de> (raw)
In-Reply-To: <20101206103836.0714369a@tlielax.poochiereds.net>
On 12/06/2010 09:08 PM, Jeff Layton wrote:
> On Mon, 06 Dec 2010 16:35:06 +0100
> Bernhard Walle <bernhard@bwalle.de> wrote:
>
>>
>> Zitat von Jeff Layton <jlayton@redhat.com>:
>>
>>>
>>> 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?
--
Suresh Jayaraman
next prev parent reply other threads:[~2010-12-09 11:40 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-05 17:07 [PATCH] cifs: Add information about noserverino Bernhard Walle
2010-12-06 6:57 ` Suresh Jayaraman
2010-12-06 14:57 ` Jeff Layton
2010-12-06 15:11 ` Bernhard Walle
2010-12-06 15:12 ` Jeff Layton
2010-12-06 15:35 ` Bernhard Walle
2010-12-06 15:38 ` Jeff Layton
2010-12-09 11:40 ` Suresh Jayaraman [this message]
2010-12-09 12:09 ` Jeff Layton
2010-12-09 18:26 ` Steve French
2010-12-09 19:34 ` Jeff Layton
2010-12-09 20:44 ` Steve French
2010-12-09 20:56 ` Jeff Layton
2010-12-10 3:09 ` Suresh Jayaraman
2010-12-10 4:58 ` Steve French
2010-12-10 11:05 ` Jeff Layton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4D00C02C.4070006@suse.de \
--to=sjayaraman@suse.de \
--cc=bernhard@bwalle.de \
--cc=jlayton@redhat.com \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=samba-technical@lists.samba.org \
--cc=sfrench@samba.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox