[systemd-devel] PATCH: do not run fsck on tmpfs mountpoint

[Kay Sievers]

On Wed, Nov 2, 2011 at 15:27, Karel Zak <kzak at redhat.com> wrote:
> On Wed, Nov 02, 2011 at 12:15:29PM +0100, Kay Sievers wrote:
>> On Wed, Nov 2, 2011 at 11:21, Frederic Crozat <fcrozat at suse.com> wrote:
>> > Le mardi 01 novembre 2011 à 16:54 +0100, Lennart Poettering a écrit :
>> >> On Thu, 27.10.11 16:19, Frederic Crozat (fcrozat at suse.com) wrote:
>> >>
>> >> > You really don't want to fsck a tmpfs, even if passno is non-null (it
>> >> > was causing many issue, forcing system to go to emergency).
>> >>
>> >> Hmm, I wonder if this is the right fix. I wonder what fsck -a does if it
>> >> finds a passno != 0 for an entry where /sbin/fsck.xxx. If that fails on
>> >> it we should probably do so too. If it silently ignores passno != 0
>> >> where the fsck is missing then we probably should implement a similar
>> >> logic. However doing an explicit check for tmpfs sounds wrong to me:
>> >> there are other fs where fsck makes little sense, and we would have to
>> >> either check them all or none?
>> >
>> > I've just checked fsck code :
>> > - it has a list of "ignore" filesystems :
>>
>> Please let's not start copying that stuff, fsck is hardly an example
>> how things should be done today. Such lists can never be up-to-date,
>> and they are not today.
>>
>> I guess, if such broken configs should be supported, which I'm really
>> not sure about, fsck itself should be made to find that out and return
>> successful without doing anything. Such things should not be guarded
>> in systemd with just another static blacklist.
>>
>> Not sure if there are valid use cases, maybe we are able to skip all
>> mounts which are not backed by a device, where major(s.st_rdev) == 0?
>
>  Unfortunately major(s.st_rdev) is probably useless, try to mount any
>  btrfs device :-)

Yeah, it was about fsck only, not mount. :)

>  BTW, in systemd/src/fsck.c I see:
>
>        /* Virtual root devices don't need an fsck */
>        if (major(st.st_dev) == 0)
>              return 0;
>
>  it means that btrfs root will be interpreted as a virtual device :-)

Oh, why do we run into the issues with tmpfs then?

Kay