Project

General

Profile

Actions
Copy link

Bug #55052

open

when mounting with new dev syntax and -o ms_mode=legacy, the option is not shown

Added by Jeff Layton about 2 years ago. Updated about 2 years ago.

Status:
New
Priority:
Normal
Assignee:
Ramana Raja
Category:
-
Target version:
-
% Done:

0%

Source:
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Crash signature (v1):
Crash signature (v2):

Description

When I mount using the new device syntax, with "-o ms_mode=legacy", I don't see the mount option in /proc/mounts.

The problem is that we just don't display ms_mode=legacy at all, which was fine when that was the clear default. /proc/mounts should display ms_mode=legacy when the new mount device syntax is used along with that option. We could also consider hiding "ms_mode=prefer-crc" if the new mount device syntax is used (since that's the new default).

Actions
Copy link
 #1

Updated by Jeff Layton about 2 years ago

  • Description updated (diff)
Actions
Copy link
 #2

Updated by Venky Shankar about 2 years ago

  • Assignee set to Ramana Raja
Actions
Copy link
 #3

Updated by Venky Shankar about 2 years ago

We probably want to move towards the mount helper not pass in ms_mode to the kernel (if one isn't specified) and let the kernel choose a sane default. Discussing with Jeff in IRC:

<jlayton> overclk: PR looks fine, but I think we might be better served long-term by not adding the ms_mode in the mount helper when one isn't specified, and instead just have the kernel decide on a sane default depending on which mount syntax was used
<overclk> jlayton: sure, that's the right approach.
<jlayton> maybe we can morph that bug that rraja__ picked up yesterday into also doing this?
<overclk> I'll have a tracker for that.
<jlayton> it's in the same area of code and is a related problem
<overclk> makes sense..
<jlayton> shouldn't be too hard to fix up, hopefully
<jlayton> I worry that down the road, we might introduce some new ms_mode variant and then the default won't make sense anymore...
<jlayton> or maybe prefer-secure becomes less of a performance burden on future hw?
<jlayton> anyway, best to keep this policy in the kernel I think
<overclk> jlayton: yeh, it would be a nightmare changing this around in mount helper.
-*- jlayton nods
Actions
Copy link

Also available in: Atom PDF