[LU-1440] mkfs.lustre: Warning: default mount option `errors=remount-ro' is missing Created: 25/May/12  Updated: 29/May/17  Resolved: 29/May/17

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: Lustre 2.2.0, Lustre 2.3.0
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Li Wei (Inactive) Assignee: WC Triage
Resolution: Cannot Reproduce Votes: 0
Labels: None

Severity: 3
Rank (Obsolete): 9754

 Description   

I'm not sure if commit 26bb579 really intended to remove "errors=remount-ro" from local.sh, but it apparently introduced a small regression:

[root@h221g tests]# MODOPTS_LNET="networks=tcp(eth1)" sh llmount.sh 
Stopping clients: h221g /mnt/lustre (opts:)
Stopping clients: h221g /mnt/lustre2 (opts:)
Loading modules from /root/lustre-release/lustre/tests/..
debug=vfstrace rpctrace dlmtrace neterror ha config ioctl super
subsystem_debug=all -lnet -lnd -pinger
../lnet/lnet/lnet options: 'networks=tcp(eth1)'
gss/krb5 is not supported
quota/lquota options: 'hash_lqs_cur_bits=3'
Formatting mgs, mds, osts
Format mds1: /tmp/lustre-mdt1
mkfs.lustre: Warning: default mount option `errors=remount-ro' is missing


 Comments   
Comment by Andreas Dilger [ 25/May/12 ]

Hmm, instead of it being included in local.sh, it should be part of mkfs_lustre.c::enable_default_ext4_features() so that it doesn't cause problems for ZFS-based backing filesystems. I guess I thought this option was now the default or something...

Comment by Andreas Dilger [ 29/May/12 ]

Looking at this more closely, it appears that the mkfs_lustre.c code on master is adding "errors=remount-ro" to the mount options internally.

Is this problem only seen during interop testing, where the .cfg file is from master, but the mkfs_lustre is running from 2.1.1? This error message "default mount option `errors=remount-ro' is missing" does not exist in master at all.

Comment by Li Wei (Inactive) [ 29/May/12 ]

Peter, I believe this warning is not affecting the testing and should not be a problem for real deployment at all.

Andreas, on a single VM, an llmount.sh shall easily trigger this warning. The warning should come from check_mountfsoptions(mountopts, default_mountopts, 0). Note that mountopts will not be changed by and after the check.

Comment by Peter Jones [ 31/May/12 ]

ok then I will drop the priority - thanks!

Comment by Andreas Dilger [ 05/Jun/12 ]

My bad, the "errors=remount-ro" option was in fact removed and needs to be re-added. The confusing thing is that in mkfs_lustre.c it is added to the "default_mountopts", but this is only used to generate this warning message. The option needs to be added to "always_mountopts" for it to be always added to the mount options, unless "errors=panic" is specified instead.

This also affects any new filesystems formatted since 26bb579a96efced8825b63b84465334368ecc382 was landed (2.1.56 and later).

Comment by Li Wei (Inactive) [ 05/Jun/12 ]

Andreas, the semantics of "--mountfsoptions" was changed a while ago, if I remember it correctly. From mkfs.lustre(8):

       --mountfsoptions=opts
              Set the mount options that will be used when mounting the backing fs.  WARNING: unlike earlier versions of mkfs.lustre, this  ver-
              sion completely replaces the default mount options with those specified on the command line, issuing a warning on stderr if any of
              the  default  mount  options  are  omitted.   The  defaults  for  ldiskfs  are  OST:  errors=remount-ro,mballoc,extents;  MGS/MDT:
              errors=remount-ro,user_xattr.  DO NOT alter the default mount options unless you know what you are doing.

Without "-mountfsoptions", mkfs.lustre adds "errors=remount-ro" and a few others according to the target type. Out test scripts should not specifying "-mountfsoptions" by default, as that is the normal usage we suggest. (I'm dropping this option by default in my Orion test patches.)

Comment by Peter Jones [ 14/Jun/12 ]

Dropping priority after discussion on 2.3 call

Comment by Andreas Dilger [ 29/May/17 ]

Close old ticket.

Generated at Sat Feb 10 01:16:39 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.