[systemd-devel] [PATCH 2/2] fsck: Add support for EFI variable based fsck indication
Kay Sievers
kay at vrfy.org
Thu Apr 9 10:05:17 PDT 2015
On Thu, Apr 9, 2015 at 6:58 PM, Reindl Harald <h.reindl at thelounge.net> wrote:
>
> Am 09.04.2015 um 18:52 schrieb Kay Sievers:
>>
>> On Thu, Apr 9, 2015 at 3:02 PM, "Jóhann B. Guðmundsson"
>> <johannbg at gmail.com> wrote:
>>
>>>> We generally follow the rule: we develop for the future, not for the
>>>> past. A file system like ext234 is clearly not the future,
>>>
>>>
>>> A filesystem like ext is being actively developed,maintained and new
>>> features being added to it.
>>>
>>> While filesystems are being supported and actively developed,maintained
>>> and
>>> new features added to them you hardly can consider them not part of the
>>> future now can you despite their "shortcomings" compared to eachother.
>>
>>
>> It is more about that:
>>
>> A filesystem which requires an out-of-kernel fsck, but has no proper
>> indication in the superblock to indicate that, and integrates that way
>> with its own fsck tool, is nothing systemd needs to work around.
>>
>> If the filesystem wants better integration, it has to provide the
>> needed features not rely on hacks on mis-use of other facilities like
>> EFI or the kernel cmdline, or flag files, to cover for the missing
>> feature.
>>
>> At a general level, an out-of-kernel fsck for a filesystem used as the
>> rootfs soulds really really weird in the year 2015. And this is not
>> neccessarily about btrfs, xfs solved that problem many many years ago
>
>
> http://linux.die.net/man/8/xfs_check
>
> "If the filesystem is very large (has many files) then xfs_check might run
> out of memory. In this case the message out of memory is printed" sounds
> really so much better than ext4....
Yeah, that is why Red Hat Enterprise Linux uses XFS as the default.
Too bad for them that they did not ask for you valuable expert
advise.
Kay
More information about the systemd-devel
mailing list