SCIENTIFIC-LINUX-USERS Archives

October 2005

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"J.Poincheval" <[log in to unmask]>
Reply To:
J.Poincheval
Date:
Wed, 12 Oct 2005 15:03:27 +0200
Content-Type:
text/plain
Parts/Attachments:
text/plain (106 lines)
Hi,

Sorry for this rather long post, i've been trying not to forget anything.

I realize the crux of the matter is probably our "advanced server for unix"
version, but since everything works fine on SL304, this may be of
interest to some people planning an SL upgrade.

Should I register bugs on the SL site for all of these ?
Have I overlooked something important which would solve everything ?

Here we go...

We've been running into quite a few problems on our SL41 x86 PCs.

Our setup involves mouting user directories using smbfs from a
tru64 unix server running ASU. This works very well on our
SL303 and SL304 workstations.

NB : everything works fine on shares served by windows servers.

Unfortunately, under SL41, we discovered that :

1 - files on our ASU/tru64 seen throught smbfs mounts now appear
    to be 4 gigabytes in size. (files on genuine windows servers are
    ok). -- see 'stat' output below.

2 - under kde or gnome, copying a file  whose  size is 4gb will indeed
    result in 4bg transfered from the server to the client (which seems
    rather normal).

3 - strangely enough, when mounting the same share using cifs, the
    file is still seen as being 4gb *but* copying it transfers only the
    right amount of data (has some cifs/smbfs/asu guru any explanation ?).
    Anyway, as this seemed to be better, I changed to using cifs.

4 - using cifs, sequential access succeeds, but seeking to the end of
    a file fails (ie : trying to open a zip file, or an openoffice
file). This
    is a direct consequence of the file appearing to weigh 4gb.

5 - last but not least, gamin (gam_server) locks the ASU shares and
    prevents us from unmounting them, with the ugly side effect of
    crashing the kernel on shutdown when everything gets unmounted
    by force.

I have a (not so elegant) solution for point n°5 : telling gamin to use
polling instead of expecting a notification by the kernel to detect
changes on mountpoints (I set a "poll /home/*" in a .gaminrc file in
users' home directories). I would have preferred to disable gamin
alltogether (fsset cifs none) but this does not seem to be available in
gamin-0.0.17-4.


Any help appreciated, some screen caps follow.

-----
* our server version (latest patches have not been applied, tru64 system
manager is quite reluctant to proceed to an upgrade on this system) :

[server] ~ > uname -a
OSF1 titi.toto.fr V5.1 1885 alpha
[server] ~ > net version
Compaq Advanced Server V5.1A ECO3 for UNIX
[server] ~ >
-----
* 'stat'ing a file on a SL304 client

[client-304 poincheval]$ stat _unix/_public/cx_locaux_tech.sxw
  File: `_unix/_public/cx_locaux_tech.sxw'
  Size: 9983            Blocks: 20         IO Block: 4096   Regular File
Device: eh/14d  Inode: 330         Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (10089/poincheval)   Gid: (65535/ UNKNOWN)
Access: 2005-10-12 11:37:22.000000000 +0200
Modify: 2005-04-14 16:15:08.000000000 +0200
Change: 2005-04-14 16:15:08.000000000 +0200

[client-304 poincheval]$ uname -a
Linux client-304 2.4.21-37.EL #1 Wed Sep 28 12:31:02 CDT 2005 i686 i686
i386 GNU/Linux

[client-304 poincheval]$ cat /etc/redhat-release
Scientific Linux SL Release 3.0.4 (SL)

-----
* 'stat'ing the same file on the SL41 machine (using cifs, smbfs results
are the same):

[client-41 ~]$ stat _unix/_public/cx_locaux_tech.sxw
  File: `_unix/_public/cx_locaux_tech.sxw'
  Size: 4294967296      Blocks: 2139095040 IO Block: 16384  fichier régulier
Device: 10h/16d Inode: 9474        Links: 0
Access: (3767/-rwxrwSrwt)  Uid: (16777216/poincheval)   Gid: (    0/
root)
Access: 2005-10-12 11:37:22.000000000 +0200
Modify: 2005-04-14 16:15:08.000000000 +0200
Change: 2005-10-11 10:35:14.000000000 +0200

* kernel has been updated, but original kernel showed the same behaviour
[client-41 ~]$ uname -a
Linux caep63.in2p3.fr 2.6.9-22.EL #1 Fri Oct 7 09:11:47 CDT 2005 i686
i686 i386 GNU/Linux

[client-41 ~]$ cat /etc/redhat-release
Scientific Linux SL release 4.1 (Beryllium)

ATOM RSS1 RSS2