bug#51425: file-system: validate flags

bug#51425: file-system: validate flags

[Jonathan Brielmaier]

Imagine the following file system definition in your config.scm:

```
(file-system
   (device (uuid "UUID-123"))
   (flags '((create-mount-point? #t)))
   (mount-point "/mnt")
   (type "ext4")))
```

When you reconfigure there will be no complain, but when you reboot your
system wont boot. The parameter to flags is nonsense, it should be
something like: `read-only`. So mounting of the file system will fail...

It would be nice if we can have some flag validation during reconfigure.

~Jonathan

bug#51425: file-system: validate flags

[Maxim Cournoyer]

Hello,

Jonathan Brielmaier <jonathan.brielmaier@web.de> writes:

> Imagine the following file system definition in your config.scm:
>
> ```
> (file-system
>   (device (uuid "UUID-123"))
>   (flags '((create-mount-point? #t)))
>   (mount-point "/mnt")
>   (type "ext4")))
> ```
>
> When you reconfigure there will be no complain, but when you reboot your
> system wont boot. The parameter to flags is nonsense, it should be
> something like: `read-only`. So mounting of the file system will fail...
>
> It would be nice if we can have some flag validation during reconfigure.
>
> ~Jonathan

I agree that it'd be nice; I had gotten close to implementing such a
thing in the past, but it was discussed and abandoned because each file
system may have their own flags, add new flags with new releases, etc,
which means it'd be difficult to keep the list accurate.

That's if my memory serves me right :-).

Thanks,

Maxim

bug#51425: file-system: validate flags

[Ludovic Courtès]

Hi!

Jonathan Brielmaier <jonathan.brielmaier@web.de> skribis:

> Imagine the following file system definition in your config.scm:
>
> ```
> (file-system
>   (device (uuid "UUID-123"))
>   (flags '((create-mount-point? #t)))
>   (mount-point "/mnt")
>   (type "ext4")))
> ```
>
> When you reconfigure there will be no complain, but when you reboot your
> system wont boot.

I suppose it fails to boot because of a match error in
‘mount-flags->bit-mask’, right?

> The parameter to flags is nonsense, it should be something like:
> `read-only`. So mounting of the file system will fail...

That’s a good use case for the recently-added ‘sanitize’ record field
property.

Ludo’.

bug#51425: file-system: validate flags

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

[FTR, I'm the one who encouraged Jonathan to file a bug.  Mount 
flags seem ideally suited to build-time validation.]

Maxim,

Maxim Cournoyer 写道：
> each file system may have their own flags

Really?  Huh.  Interesting.  How does that work?  Where would 
these file-system specific flags be #defined?

(My guess is that if anyone does this, it'd be ZFS ;-)

> add new flags with new [Linux] releases

Well, sure, but then we simply add them to Guix.  This applies to 
everything from syscalls to services.

Ludo', I'll take a look at ‘sanitize’; thanks!

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#51425: file-system: validate flags

[Maxim Cournoyer]

Hello Tobias,

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> [FTR, I'm the one who encouraged Jonathan to file a bug.  Mount flags
> seem ideally suited to build-time validation.]
>
> Maxim,
>
> Maxim Cournoyer 写道：
>> each file system may have their own flags
>
> Really?  Huh.  Interesting.  How does that work?  Where would these
> file-system specific flags be #defined?

Or maybe I'm confusing with file system options; I can't find the past
discussion that I had on mind; but options are file driver specific,
while flags are file system independent.  So yes, flags are a good
candidate for validation!

Another thing that is tricky about options is that some of them are only
really understood by the 'mount' command line utility, not the 'mount'
system call such as used in our init RAM disk (both are thrown together
in 'man 8 mount' without an easy way to discern them apart, IIRC).

> Ludo', I'll take a look at ‘sanitize’; thanks!

Neat, thank you Tobias!

Maxim

bug#51425: file-system: validate flags

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]

Maxim,

Maxim Cournoyer 写道：
> Another thing that is tricky about options is that some of them 
> are only
> really understood by the 'mount' command line utility, not the 
> 'mount'
> system call such as used in our init RAM disk (both are thrown 
> together
> in 'man 8 mount' without an easy way to discern them apart, 
> IIRC).

Aha!  Let me introduce you to the only slightly unfortunately 
named ‘man 2 mount’ instead.

The way mount(8) lumps both together is… I guess it's 
user-friendly — in a way? — but it leads to this total confusion 
about what's what.  Think of flags as literal bit flags, mainly 
because they are.

Guix does make the distinction.  It's the right call but it leads 
to a brief education moment the first time you encounter both 
fields.

You're absolutely right that mount options OTOH are arbitrary 
strings.  They can't and shouldn't be ‘validated’, but we don't 
currently mandate their stringiness, and should.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

bug#51425: file-system: validate flags

[Maxim Cournoyer]

Hi Tobias,

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> Maxim,
>
> Maxim Cournoyer 写道：
>> Another thing that is tricky about options is that some of them are
>> only
>> really understood by the 'mount' command line utility, not the
>> 'mount'
>> system call such as used in our init RAM disk (both are thrown
>> together
>> in 'man 8 mount' without an easy way to discern them apart, IIRC).
>
> Aha!  Let me introduce you to the only slightly unfortunately named
> ‘man 2 mount’ instead.

Eh, I'm not sure why I hadn't thought about that myself, thank you!  It
makes sense after all -- one man page (2) documents the options for the
system call, the other one (8) for the command.

> The way mount(8) lumps both together is… I guess it's user-friendly —
> in a way? — but it leads to this total confusion about what's what.
> Think of flags as literal bit flags, mainly because they are.

Hehe.

> Guix does make the distinction.  It's the right call but it leads to a
> brief education moment the first time you encounter both fields.
>
> You're absolutely right that mount options OTOH are arbitrary strings.
> They can't and shouldn't be ‘validated’, but we don't currently
> mandate their stringiness, and should.

Makes sense.

Thank you!

Maxim

bug#51425: file-system: validate flags

[Ludovic Courtès]

Hi,

Ludovic Courtès <ludo@gnu.org> skribis:

> Jonathan Brielmaier <jonathan.brielmaier@web.de> skribis:
>
>> Imagine the following file system definition in your config.scm:
>>
>> ```
>> (file-system
>>   (device (uuid "UUID-123"))
>>   (flags '((create-mount-point? #t)))
>>   (mount-point "/mnt")
>>   (type "ext4")))
>> ```
>>
>> When you reconfigure there will be no complain, but when you reboot your
>> system wont boot.
>
> I suppose it fails to boot because of a match error in
> ‘mount-flags->bit-mask’, right?
>
>> The parameter to flags is nonsense, it should be something like:
>> `read-only`. So mounting of the file system will fail...
>
> That’s a good use case for the recently-added ‘sanitize’ record field
> property.

Done in 5eb5c0789f34e87ee417a53ddfcfa3b6521bb337.

Thanks,
Ludo’.