[LU-11351] using max_sectors_kb=0 in persistent mount options doesn't work Created: 07/Sep/18  Updated: 27/Feb/20  Resolved: 27/Feb/20

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: Lustre 2.10.5
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Mahmoud Hanafi Assignee: Peter Jones
Resolution: Fixed Votes: 0
Labels: None

Severity: 3
Rank (Obsolete): 9223372036854775807

 Description   

When you set max_sectors_kb=0 as a persistent mount options it fails to mount

You get this error:

[1474.604509] LDISKFS-fs (dm-1): Unrecognized mount option "max_sectors_kb=0" or missing value

Passing it as a mount option works.



 Comments   
Comment by Andreas Dilger [ 10/Sep/18 ]

How are you setting max_sectors_kb=0 as a persistent mount option? This option is parsed by mount.lustre, but it looks like it is being passed to ldiskfs, which doesn't understand it.

Comment by Mahmoud Hanafi [ 10/Sep/18 ]

Currently we are passing during mount

mount -t lustre -o max_sectors_kb=0 ....

This should work when set in persistent mount settings.

Comment by Andreas Dilger [ 11/Sep/18 ]

Sorry, your answer still isn't clear to me. When you say "set in persistent mount settings" do you mean "set in /etc/fstab" or something else?

Comment by Mahmoud Hanafi [ 11/Sep/18 ]

Persistent ---> setting the option via tunefs.lustre


tunefs.lustre --mountfsoptions="acl,errors=panic,user_xattr,max_sectors_kb=0"
 

 

Comment by Andreas Dilger [ 12/Sep/18 ]

The tunefs.lustre mount options are for the underlying filesystem. For Lustre mounts, you should add this option to /etc/fstab.

Comment by Mahmoud Hanafi [ 13/Sep/18 ]

If you run

 mount -t lustre /dev/ostx /mnt/ost

This will not use any of the default values stored using tunefs.lustre?

 

Comment by Andreas Dilger [ 14/Sep/18 ]

Yes, it will. But these options are applied to the underlying filesystem mount inside the kernel. The options in /etc/fstab are parsed by mount.lustre, which applies this particular tunable in userspace.

Comment by Mahmoud Hanafi [ 27/Feb/20 ]

Please close this

Generated at Sat Feb 10 02:43:07 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.