[linux-cifs-client] [PATCH 0/7] [CIFS] RFC: implement ability to specify remote_nls for legacy servers

[Jeff Layton]

On Mon, 28 Jul 2008 16:08:04 +0200 (CEST)
Marko Käning <mk362 at mch.osram.de> wrote:

> Hi Jeff,
> 
> > Since this patchset will use unicode as an intermediate translation
> > format, you'll probably have the same problem even afterward.
> 
> I see.
> 
> 
> > What NLS table is your kernel using and how often do you see these 
> > messages?
> 
> Well, I don't know how to tell you which NLS table my kernel is using. 
> Please tell me, how I can give you this info. 
> (Calling "find /proc -name *nls*" doesn't give me any hint.)
> 

I'm not sure how you tell at runtime (I'm still getting my feet wet
with NLS stuff here). I think it's mostly a build time option:

    CONFIG_NLS_DEFAULT

...all recent RHEL and Fedora kernels are using utf8. If you're not, you
may want to try switching to that on both ends and see if it helps.

> After letting storeBackup do my server backup onto another linux server 
> 
> ---
> client machine:
>  Linux client 2.6.22.18-0.2-default #1 SMP 2008-06-09 13:53:20 +0200 i686 i686 i386 GNU/Linux
>   with Samba 3.0.26a
> --- 
> remote server:
>  Linux server 2.6.16.53-0.8-smp #1 SMP Fri Aug 31 13:07:27 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux
>   with Samba 3.0.22
> ---
> 
> I see for approximately 38000 files in 9000 folders 4435 times these 
> errors happen:
> 
> ---
> flmpc35:~ # egrep "^Jul 25.*strtoUCS" /var/log/messages | wc
>    4435   57655  361609
> ---
> 
> And it is always -4 or -28 which returns the error -22.
> 
>      !!! MORE THAN FOUR THOUSAND ERRORS!!!
> 
> I wasn't aware myself up to now that the number of messages is actually 
> that big. Good that you asked me!
> 
> 
> It is strange, but these messages only appear when I shove my backup onto
> the server. When I pull the backup files back there are no such messages.
> 
> storeBackup is also able to successfully recover its backups from the said 
> server... Weird!
> 
> 
> ???????????????
> 
> Well, concerning the error messages it would probably very helpful to know 
> which paths caused the trouble! Perhaps I should run my client with some 
> debug level switch?
> 
> ???????????????
> 

Since you're working with so many files, turning up cifsFYI or
something is going to be expensive. What you might want to do is
instrument your kernel so that it does a dump_stack() after throwing
this warning and/or have it print out the string that is causing the
warning. Something like this patch might do it (untested, even for
compilation, so YMMV).

-- 
Jeff Layton <jlayton at redhat.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cifs-strtoucs-dump-stack.patch
Type: text/x-patch
Size: 1267 bytes
Desc: not available
Url : http://lists.samba.org/archive/linux-cifs-client/attachments/20080728/58db819d/cifs-strtoucs-dump-stack.bin