Lustre discuss - May 2010 - Problems with fstab entry on sles11

Hello Folks,

i guad probelms with the fstab entry.
The lustre filesystem doesnt startup on boot.
A mount -a after reboot start the lustre filesystem.
Whats the problem?
Is there something special with SLES11.

Here are some infos about our client configuration.

snowball003:~ # cat /etc/fstab

/dev/os/swap         swap                 swap       
defaults              0 0

/dev/os/root         /                    reiserfs   
defaults              1 1

/dev/disk/by-id/ata-HITACHI_HUA7250SBSUN500G_0938JVHU3E_GTA470P6GVHU3E-part2 
/boot                reiserfs   acl,user_xattr        1 2

/dev/os/home         /export/home         reiserfs   
defaults              1 2

/dev/os/opt          /opt                 reiserfs   
defaults              1 2

/dev/os/usr          /usr                 reiserfs   
defaults              1 2

/dev/os/var          /var                 reiserfs   
defaults              1 2

proc                 /proc                proc       
defaults              0 0

sysfs                /sys                 sysfs      
noauto                0 0

debugfs              /sys/kernel/debug    debugfs    
noauto                0 0

usbfs                /proc/bus/usb        usbfs      
noauto                0 0

devpts               /dev/pts             devpts     
mode=0620,gid=5       0 0

192.168.103.224 at tcp,192.168.103.223 at tcp:/snowbfs 
/export/scratch_snowball lustre _netdev 0 0

snowball003:~ # uname -a

Linux snowball003 2.6.27.39-0.3_lustre.1.8.2-default #1 SMP 2009-11-23 
12:57:38 +0100 x86_64 x86_64 x86_64 GNU/Linux

snowball003:~ # rpm -qa | egrep "lustre|e2fs"

lustre-ldiskfs-3.0.9-2.6.27.39_0.3_lustre.1.8.2_default

kernel-source-2.6.27.39-0.3_lustre.1.8.2

kernel-default-base-2.6.27.39-0.3_lustre.1.8.2

kernel-ib-1.4.2-2.6.27.39_0.3_lustre.1.8.2_default.volt3408

kernel-default-2.6.27.39-0.3_lustre.1.8.2

kernel-ib-devel-1.4.2-2.6.27.39_0.3_lustre.1.8.2_default.volt3408

lustre-1.8.2-2.6.27.39_0.3_lustre.1.8.2_default

kernel-default-extra-2.6.27.39-0.3_lustre.1.8.2

e2fsprogs-1.41.1-13.11.1

lustre-modules-1.8.2-2.6.27.39_0.3_lustre.1.8.2_default



Thanks and regards

Matthias
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.lustre.org/pipermail/lustre-discuss/attachments/20100503/41ecc6a9/attachment.html

On Mon, 2010-05-03 at 13:18 +0200, Matthias Wolf wrote:
> Hello Folks,
> 
> i guad probelms with the fstab entry.
> The lustre filesystem doesnt startup on boot.
> A mount -a after reboot start the lustre filesystem.
> Whats the problem?
> Is there something special with SLES11.
Yes, there is.

Lustre, of course, requires the network to be available when it wants to
mount, but typically, mounting of filesystems happens before network
availability.

Historically, this has been handled by adding a "_netdev" option to
the
fstab for filesystems that require the network in order to mount.  This
causes the "first pass" mount to skip those mounts and a "second
pass"
mount is done after the network is up to catch the _netdev entries.

Some time ago Suse dropped support for _netdev.  I filed this as bug
331255 in Novell''s bugzilla back in 2007.  There was some discussion,
but the _netdev functionality was never resurrected.  I also filed bug
13714 in our own bugzilla to track the issue, but it seems to have never
come to a final resolution.  :-/

Perhaps other SLES users here can post ideas on how they handle this
situation.  I guess for those using heartbeat, this is a non-issue as
heartbeat handles the mounting and heartbeat is started after
networking.

b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url :
http://lists.lustre.org/pipermail/lustre-discuss/attachments/20100503/6f5ab993/attachment.bin

>Perhaps other SLES users here can post ideas on how they handle this
>situation.  I guess for those using heartbeat, this is a non-issue as
>heartbeat handles the mounting and heartbeat is started after
>networking.
So, as a SLES user, let me offer my $0.02.

_netdev still works in the sense that it prevents the mount command from
mounting those filesystems at the normal time.  But there''s nothing
that
comes around and mounts those after the network is up (which drove me
nuts for a while, because the documentation hasn''t changed).

As far as I can tell, your only option is to create a (presumably simple)
script that goes and mounts your Lustre filesystem after the network is
up.  Our script is more complicated because it has to wait until the
Infiniband network is up and the storage is available.

--Ken

On 5/3/10 10:43 AM, Ken Hornstein wrote:
>> Perhaps other SLES users here can post ideas on how they handle this
>> situation.  I guess for those using heartbeat, this is a non-issue as
>> heartbeat handles the mounting and heartbeat is started after
>> networking.
>
> So, as a SLES user, let me offer my $0.02.
>
> _netdev still works in the sense that it prevents the mount command from
> mounting those filesystems at the normal time.  But there''s
nothing that
> comes around and mounts those after the network is up (which drove me
> nuts for a while, because the documentation hasn''t changed).
>
> As far as I can tell, your only option is to create a (presumably simple)
> script that goes and mounts your Lustre filesystem after the network is
> up.  Our script is more complicated because it has to wait until the
> Infiniband network is up and the storage is available.
>
Another alternative is to automount on demand (man 5 autofs), though there
are some issues with that (e.g. sometimes /etc/mtab is updated so autofs
thinks its mounted but it really isn''t).  Clean shutdown is also
somewhat
of a problem, especially with IB (e.g. openibd won''t unload if its in
use
by Lustre).

On Mon, 2010-05-03 at 10:43 -0400, Ken Hornstein wrote: 
> 
> _netdev still works in the sense that it prevents the mount command from
> mounting those filesystems at the normal time.
Yes, I believe this was covered in one of the bugs I pointed to, but
worth mentioning here.
> But there''s nothing that
> comes around and mounts those after the network is up
Indeed.
> As far as I can tell, your only option is to create a (presumably simple)
> script that goes and mounts your Lustre filesystem after the network is
> up.
Or resurrect the "netfs" initscript from somewhere that does this
second
phase network dependent mounting.

b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url :
http://lists.lustre.org/pipermail/lustre-discuss/attachments/20100503/b8d16b84/attachment.bin

On Mon, 2010-05-03 at 10:55 -0400, Dardo D Kleiner - CONTRACTOR wrote:
> 
> Another alternative is to automount on demand (man 5 autofs), though there
> are some issues with that
Yeah, as discussed here not that long ago, there are other issues with
this even.  There might be a bug in BZ about it by now even.  Hopefully
whoever was reporting the problems here filed a bug.

b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url :
http://lists.lustre.org/pipermail/lustre-discuss/attachments/20100503/d028e51d/attachment.bin