Re: [f2fs-dev] Possible issues with fsck of f2fs root
On 2020/7/27 23:02, Michael Laß wrote: Am Samstag, den 25.07.2020, 10:06 +0800 schrieb Chao Yu: On 2020/7/24 16:11, Norbert Lange wrote: $ fsck.f2fs -a /dev/mmcblk0p5; echo $? Info: Fix the reported corruption. Info: Mounted device! Info: Check FS only on RO mounted device Error: Failed to open the device! 255 I tried ext4, it acts the same as f2fs... except different return value. fsck -t ext4 -a /dev/zram1; echo $? fsck 1.45.0 (6-Mar-2019) /dev/zram1 is mounted. e2fsck: Cannot continue, aborting. 8 fsck -t ext4 -a -f /dev/zram1; echo $? fsck 1.45.0 (6-Mar-2019) Warning! /dev/zram1 is mounted. /dev/zram1: 11/1179648 files (0.0% non-contiguous), 118065/4718592 blocks 0 I'd like to know what behavior of fsck does systemd expect? fsck -a should work (check & report or check & report & repaire) on readonly mounted device? I think the return value is exactly the problem here. See fsck(8) ( https://linux.die.net/man/8/fsck) which specifies the return values. Systemd looks at these and decides how to proceed: https://github.com/systemd/systemd/blob/a859abf062cef1511e4879c4ee39c6036ebeaec8/src/fsck/fsck.c#L407 That means, if fsck.f2fs returns 255, then the FSCK_SYSTEM_SHOULD_REBOOT bit is set and systemd will reboot. Thanks for pointing this out, will fix this soon. Thanks, Best regards, Michael . ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] Possible issues with fsck of f2fs root
Am Samstag, den 25.07.2020, 10:06 +0800 schrieb Chao Yu: > On 2020/7/24 16:11, Norbert Lange wrote: > > > > $ fsck.f2fs -a /dev/mmcblk0p5; echo $? > > Info: Fix the reported corruption. > > Info: Mounted device! > > Info: Check FS only on RO mounted device > > Error: Failed to open the device! > > 255 > > I tried ext4, it acts the same as f2fs... except different return > value. > > fsck -t ext4 -a /dev/zram1; echo $? > fsck 1.45.0 (6-Mar-2019) > /dev/zram1 is mounted. > e2fsck: Cannot continue, aborting. > > > 8 > > fsck -t ext4 -a -f /dev/zram1; echo $? > fsck 1.45.0 (6-Mar-2019) > Warning! /dev/zram1 is mounted. > /dev/zram1: 11/1179648 files (0.0% non-contiguous), 118065/4718592 > blocks > 0 > > I'd like to know what behavior of fsck does systemd expect? > fsck -a should work (check & report or check & report & repaire) > on readonly mounted device? I think the return value is exactly the problem here. See fsck(8) ( https://linux.die.net/man/8/fsck) which specifies the return values. Systemd looks at these and decides how to proceed: https://github.com/systemd/systemd/blob/a859abf062cef1511e4879c4ee39c6036ebeaec8/src/fsck/fsck.c#L407 That means, if fsck.f2fs returns 255, then the FSCK_SYSTEM_SHOULD_REBOOT bit is set and systemd will reboot. Best regards, Michael ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] Possible issues with fsck of f2fs root
On 2020/7/24 16:11, Norbert Lange wrote: Hello, I ran into this problem with fsck.f2fs 1.13.0, it seems that problem is not fixed in master either. My setup is an embedded device with systemd and I did nothing but swap the filesystem from ext4 to f2fs. The result was that the init system would try to fsck the ro mounted root partition, fsck.f2fs would fail (as noted), and the init system would reboot (rinse, repeat) with no real chance to interact remotely (headless system). Thats pretty much as bad as it gets for an unwanted sideffect ;) I first reported it to systemd, quite reasonably they expect fsck tools to behave the same [1]. The systemd-fsck tool will end up calling fsck.f2fs with the parameter below, and will fail as this device is mounted (tries to open it in exclusive mode). $ fsck.f2fs -a /dev/mmcblk0p5; echo $? Info: Fix the reported corruption. Info: Mounted device! Info: Check FS only on RO mounted device Error: Failed to open the device! 255 I tried ext4, it acts the same as f2fs... except different return value. fsck -t ext4 -a /dev/zram1; echo $? fsck 1.45.0 (6-Mar-2019) /dev/zram1 is mounted. e2fsck: Cannot continue, aborting. 8 fsck -t ext4 -a -f /dev/zram1; echo $? fsck 1.45.0 (6-Mar-2019) Warning! /dev/zram1 is mounted. /dev/zram1: 11/1179648 files (0.0% non-contiguous), 118065/4718592 blocks 0 I'd like to know what behavior of fsck does systemd expect? fsck -a should work (check & report or check & report & repaire) on readonly mounted device? Thanks, A workaround would be to force or skip the check fsck.f2fs -a -f /dev/mmcblk0p5; echo $? Info: Fix the reported corruption. . Done: 0.232165 secs 0 So, Id consider this a critical issue, and I dont see whats the conclusion of this discussion is. Norbert [1] - https://github.com/systemd/systemd/issues/15106 . ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] Possible issues with fsck of f2fs root
Hello, I ran into this problem with fsck.f2fs 1.13.0, it seems that problem is not fixed in master either. My setup is an embedded device with systemd and I did nothing but swap the filesystem from ext4 to f2fs. The result was that the init system would try to fsck the ro mounted root partition, fsck.f2fs would fail (as noted), and the init system would reboot (rinse, repeat) with no real chance to interact remotely (headless system). Thats pretty much as bad as it gets for an unwanted sideffect ;) I first reported it to systemd, quite reasonably they expect fsck tools to behave the same [1]. The systemd-fsck tool will end up calling fsck.f2fs with the parameter below, and will fail as this device is mounted (tries to open it in exclusive mode). $ fsck.f2fs -a /dev/mmcblk0p5; echo $? Info: Fix the reported corruption. Info: Mounted device! Info: Check FS only on RO mounted device Error: Failed to open the device! 255 A workaround would be to force or skip the check fsck.f2fs -a -f /dev/mmcblk0p5; echo $? Info: Fix the reported corruption. . Done: 0.232165 secs 0 So, Id consider this a critical issue, and I dont see whats the conclusion of this discussion is. Norbert [1] - https://github.com/systemd/systemd/issues/15106 ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] Possible issues with fsck of f2fs root
On 2019/4/24 0:17, Hagbard Celine wrote: > 2019-04-23 4:55 GMT+02:00, Chao Yu : >> On 2019/4/22 18:05, Hagbard Celine wrote: >>> 2019-04-22 11:26 GMT+02:00, Chao Yu : On 2019/4/22 17:05, Hagbard Celine wrote: > 2019-04-22 9:37 GMT+02:00, Chao Yu : >> On 2019/4/22 15:11, Hagbard Celine wrote: >>> With this patch the one problem with opening the device in RO mode is >>> fixed. >> >> Oops, with default preen mode fsck should not open ro mounted image, >> that's >> the >> rule we keep line with ext4... >> >> How about changing to use -f in your scenario ( on RO mounted root >> image >> )? > > This was with -f. Without -f it still refuses to open the device. What I mean is we'd better to keep line with ext4, just refusing to open ro mounted device without -f, since triggering fsck and repair on a mounted device is dangerous, it can easily make inconsistency in between in-memory data and on-disk data of filesystem. Refusing fsck without -f is to make user being aware of such danger. >>> >>> I am sorry, I've apparently added the -f after my first report. After >>> re-testing it seems that fsck.f2fs is opening the RO partition even >>> without this patch if I use -f. So the part about fsck.f2fs not being >>> able to open RO mounted partition during boot was a user error. >> >> I've sent a patch for your second issue, could you please have a try with >> it? >> >> [PATCH] fsck.f2fs: fix to repair ro mounted device w/ -f >> >> But one concern is that, with this patch, not like the fsck.ext4, fsck.f2fs >> won't show any interaction with below reminding word to remind user to >> decide >> repair or not, it may increase the risk of damaging the device. >> >> Do you want to restore lost files into ./lost_found/? >> Do you want to fix this partition? [Y/N] >> >> Jaegeuk, Hagbard, >> >> Any suggestion on this, in current scenario, how about implement: >> 1. fsck.f2fs -f ro_mounted_device: check; show interaction words if there >> is >> corruption; >> 2. fsck.f2fs -f -a ro_moutned_device: check and repair automatically; > > I answered this all too quickly and did not think it trough properly. > As it stands today, if I run "fsck.f2fs -f /dev/some_unmounted_disk" > it will always do a full fsck. > If I on the other hand do "fsck.f2fs -f -a /dev/some_unmounted_disk" > it sometimes only reads the checkpoint state and returns with: "Info: > No errors was reported". > I do not have a ext4 partition with errors to test, but I have a fat It can easily be generated by debugfs with: debugfs: open /dev/zram0 -w debugfs: sif file extra_isize 19 > partition that comes up with "Free cluster summary wrong" on every run > of fsck.fat and there fsck asks for confirmation when run with "-f" > and autofixes without asking when running with "-f -a". For some_unmounted_disk, fsck.ext4 shows the same behavior like fsck.fat: # fsck.ext4 /dev/zram0 -f e2fsck 1.45.0 (6-Mar-2019) Pass 1: Checking inodes, blocks, and sizes Inode 12 has a extra size (19) which is invalid Fix? /dev/zram0: e2fsck canceled. # fsck.ext4 /dev/zram0 -f -a /dev/zram0: Inode 12 has a extra size (19) which is invalid FIXED. Also on a RO_mounted_disk, the behavior of fsck.ext4 is the same, so, it looks like we actually need another patch to fix fsck.f2fs' behavior for "-f" and "-f -a" on umounted/ro_mounted device. Thanks, > > Considering this I believe the proposed solution would be > counter-intuitive, unless fsck.ext4 behaves opposite of fsck.fat > already. >> >> Thanks, >> >>> Thanks, > > >> Thanks, >> >>> But as far as I can understand it will still only check the fs, not >>> fix >>> it. >>> >>> >>> 2019-04-21 12:27 GMT+02:00, Jaegeuk Kim : >>> New version of the patch is: From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00 2001 From: Jaegeuk Kim Date: Tue, 16 Apr 2019 11:46:31 -0700 Subject: [PATCH] fsck.f2fs: open ro disk if we want to check fs only This patch fixes the "open failure" issue on ro disk, reported by Hagbard. " If I boot with kernel option "ro rootfstype=f2fs I get the following halfway trough boot: * Checking local filesystems ... Info: Use default preen mode Info: Mounted device! Info: Check FS only due to RO Error: Failed to open the device! * Filesystems couldn't be fixed " Reported-by: Hagbard Celine Signed-off-by: Jaegeuk Kim --- lib/libf2fs.c | 25 + 1 file changed, 21 insertions(+), 4 deletions(-) diff --git a/lib/libf2fs.c b/lib/libf2fs.c index d30047f..853e713 100644 --- a/lib/libf2fs.c +++ b/lib/l
Re: [f2fs-dev] Possible issues with fsck of f2fs root
2019-04-23 4:55 GMT+02:00, Chao Yu :
> On 2019/4/22 18:05, Hagbard Celine wrote:
>> 2019-04-22 11:26 GMT+02:00, Chao Yu :
>>> On 2019/4/22 17:05, Hagbard Celine wrote:
2019-04-22 9:37 GMT+02:00, Chao Yu :
> On 2019/4/22 15:11, Hagbard Celine wrote:
>> With this patch the one problem with opening the device in RO mode is
>> fixed.
>
> Oops, with default preen mode fsck should not open ro mounted image,
> that's
> the
> rule we keep line with ext4...
>
> How about changing to use -f in your scenario ( on RO mounted root
> image
> )?
This was with -f. Without -f it still refuses to open the device.
>>>
>>> What I mean is we'd better to keep line with ext4, just refusing to open
>>> ro
>>> mounted device without -f, since triggering fsck and repair on a mounted
>>> device
>>> is dangerous, it can easily make inconsistency in between in-memory data
>>> and
>>> on-disk data of filesystem. Refusing fsck without -f is to make user
>>> being
>>> aware
>>> of such danger.
>>
>> I am sorry, I've apparently added the -f after my first report. After
>> re-testing it seems that fsck.f2fs is opening the RO partition even
>> without this patch if I use -f. So the part about fsck.f2fs not being
>> able to open RO mounted partition during boot was a user error.
>
> I've sent a patch for your second issue, could you please have a try with
> it?
>
> [PATCH] fsck.f2fs: fix to repair ro mounted device w/ -f
>
> But one concern is that, with this patch, not like the fsck.ext4, fsck.f2fs
> won't show any interaction with below reminding word to remind user to
> decide
> repair or not, it may increase the risk of damaging the device.
>
> Do you want to restore lost files into ./lost_found/?
> Do you want to fix this partition? [Y/N]
>
> Jaegeuk, Hagbard,
>
> Any suggestion on this, in current scenario, how about implement:
> 1. fsck.f2fs -f ro_mounted_device: check; show interaction words if there
> is
> corruption;
> 2. fsck.f2fs -f -a ro_moutned_device: check and repair automatically;
I answered this all too quickly and did not think it trough properly.
As it stands today, if I run "fsck.f2fs -f /dev/some_unmounted_disk"
it will always do a full fsck.
If I on the other hand do "fsck.f2fs -f -a /dev/some_unmounted_disk"
it sometimes only reads the checkpoint state and returns with: "Info:
No errors was reported".
I do not have a ext4 partition with errors to test, but I have a fat
partition that comes up with "Free cluster summary wrong" on every run
of fsck.fat and there fsck asks for confirmation when run with "-f"
and autofixes without asking when running with "-f -a".
Considering this I believe the proposed solution would be
counter-intuitive, unless fsck.ext4 behaves opposite of fsck.fat
already.
>
> Thanks,
>
>>
>>>
>>> Thanks,
>>>
> Thanks,
>
>> But as far as I can understand it will still only check the fs, not
>> fix
>> it.
>>
>>
>> 2019-04-21 12:27 GMT+02:00, Jaegeuk Kim :
>>
>>>
>>> New version of the patch is:
>>>
>>> From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00
>>> 2001
>>> From: Jaegeuk Kim
>>> Date: Tue, 16 Apr 2019 11:46:31 -0700
>>> Subject: [PATCH] fsck.f2fs: open ro disk if we want to check fs only
>>>
>>> This patch fixes the "open failure" issue on ro disk, reported by
>>> Hagbard.
>>>
>>> "
>>> If I boot with kernel option "ro rootfstype=f2fs
>>> I get the following halfway trough boot:
>>>
>>> * Checking local filesystems ...
>>> Info: Use default preen mode
>>> Info: Mounted device!
>>> Info: Check FS only due to RO
>>> Error: Failed to open the device!
>>> * Filesystems couldn't be fixed
>>> "
>>>
>>> Reported-by: Hagbard Celine
>>> Signed-off-by: Jaegeuk Kim
>>> ---
>>> lib/libf2fs.c | 25 +
>>> 1 file changed, 21 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/lib/libf2fs.c b/lib/libf2fs.c
>>> index d30047f..853e713 100644
>>> --- a/lib/libf2fs.c
>>> +++ b/lib/libf2fs.c
>>> @@ -789,6 +789,15 @@ void get_kernel_uname_version(__u8 *version)
>>> #endif /* APPLE_DARWIN */
>>>
>>> #ifndef ANDROID_WINDOWS_HOST
>>> +static int open_check_fs(char *path, int flag)
>>> +{
>>> + if (c.func != FSCK || c.fix_on || c.auto_fix)
>>> + return -1;
>>> +
>>> + /* allow to open ro */
>>> + return open(path, O_RDONLY | flag);
>>> +}
>>> +
>>> int get_device_info(int i)
>>> {
>>> int32_t fd = 0;
>>> @@ -810,8 +819,11 @@ int get_device_info(int i)
>>> if (c.sparse_mode) {
>>> fd = open(dev->path, O_RDWR | O_CREAT | O_BINARY, 0644);
>>> if (fd < 0) {
>>> - MSG(0, "\tError: Failed to open a sparse
>>> file!\n");
>>> -
Re: [f2fs-dev] Possible issues with fsck of f2fs root
2019-04-23 13:59 GMT+02:00, Hagbard Celine :
> 2019-04-23 4:55 GMT+02:00, Chao Yu :
>> On 2019/4/22 18:05, Hagbard Celine wrote:
>>> 2019-04-22 11:26 GMT+02:00, Chao Yu :
On 2019/4/22 17:05, Hagbard Celine wrote:
> 2019-04-22 9:37 GMT+02:00, Chao Yu :
>> On 2019/4/22 15:11, Hagbard Celine wrote:
>>> With this patch the one problem with opening the device in RO mode
>>> is
>>> fixed.
>>
>> Oops, with default preen mode fsck should not open ro mounted image,
>> that's
>> the
>> rule we keep line with ext4...
>>
>> How about changing to use -f in your scenario ( on RO mounted root
>> image
>> )?
>
> This was with -f. Without -f it still refuses to open the device.
What I mean is we'd better to keep line with ext4, just refusing to
open
ro
mounted device without -f, since triggering fsck and repair on a
mounted
device
is dangerous, it can easily make inconsistency in between in-memory
data
and
on-disk data of filesystem. Refusing fsck without -f is to make user
being
aware
of such danger.
>>>
>>> I am sorry, I've apparently added the -f after my first report. After
>>> re-testing it seems that fsck.f2fs is opening the RO partition even
>>> without this patch if I use -f. So the part about fsck.f2fs not being
>>> able to open RO mounted partition during boot was a user error.
>>
>> I've sent a patch for your second issue, could you please have a try with
>> it?
>>
>> [PATCH] fsck.f2fs: fix to repair ro mounted device w/ -f
>
> Tested by forcing a sudden_power_off by reset-switch, seems to work.
>
>> But one concern is that, with this patch, not like the fsck.ext4,
>> fsck.f2fs
>> won't show any interaction with below reminding word to remind user to
>> decide
>> repair or not, it may increase the risk of damaging the device.
>>
>> Do you want to restore lost files into ./lost_found/?
>> Do you want to fix this partition? [Y/N]
>>
>> Jaegeuk, Hagbard,
>>
>> Any suggestion on this, in current scenario, how about implement:
>> 1. fsck.f2fs -f ro_mounted_device: check; show interaction words if there
>> is
>> corruption;
>> 2. fsck.f2fs -f -a ro_moutned_device: check and repair automatically;
>
> I guess that would be ok. Just to mention: Gentoo defaults to "fsck -A
> -p" during boot, where I can add the "-f" option by config file. I am
> not up to date on what other distros uses for default
> options in their fsck command during boot.
Please ignore that part about defaults, I misread the script: if I set
-f in config file it replaces the default -p, I checked with "set -o
xtrace".
>
>> Thanks,
>>
>>>
Thanks,
>
>
>> Thanks,
>>
>>> But as far as I can understand it will still only check the fs, not
>>> fix
>>> it.
>>>
>>>
>>> 2019-04-21 12:27 GMT+02:00, Jaegeuk Kim :
>>>
New version of the patch is:
From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00
2001
From: Jaegeuk Kim
Date: Tue, 16 Apr 2019 11:46:31 -0700
Subject: [PATCH] fsck.f2fs: open ro disk if we want to check fs
only
This patch fixes the "open failure" issue on ro disk, reported by
Hagbard.
"
If I boot with kernel option "ro rootfstype=f2fs
I get the following halfway trough boot:
* Checking local filesystems ...
Info: Use default preen mode
Info: Mounted device!
Info: Check FS only due to RO
Error: Failed to open the device!
* Filesystems couldn't be fixed
"
Reported-by: Hagbard Celine
Signed-off-by: Jaegeuk Kim
---
lib/libf2fs.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/lib/libf2fs.c b/lib/libf2fs.c
index d30047f..853e713 100644
--- a/lib/libf2fs.c
+++ b/lib/libf2fs.c
@@ -789,6 +789,15 @@ void get_kernel_uname_version(__u8 *version)
#endif /* APPLE_DARWIN */
#ifndef ANDROID_WINDOWS_HOST
+static int open_check_fs(char *path, int flag)
+{
+ if (c.func != FSCK || c.fix_on || c.auto_fix)
+ return -1;
+
+ /* allow to open ro */
+ return open(path, O_RDONLY | flag);
+}
+
int get_device_info(int i)
{
int32_t fd = 0;
@@ -810,8 +819,11 @@ int get_device_info(int i)
if (c.sparse_mode) {
fd = open(dev->path, O_RDWR | O_CREAT | O_BINARY, 0644);
if (fd < 0) {
- MSG(0, "\tError: Failed to open a sparse
file!\n");
- return -1;
+
Re: [f2fs-dev] Possible issues with fsck of f2fs root
2019-04-23 4:55 GMT+02:00, Chao Yu :
> On 2019/4/22 18:05, Hagbard Celine wrote:
>> 2019-04-22 11:26 GMT+02:00, Chao Yu :
>>> On 2019/4/22 17:05, Hagbard Celine wrote:
2019-04-22 9:37 GMT+02:00, Chao Yu :
> On 2019/4/22 15:11, Hagbard Celine wrote:
>> With this patch the one problem with opening the device in RO mode is
>> fixed.
>
> Oops, with default preen mode fsck should not open ro mounted image,
> that's
> the
> rule we keep line with ext4...
>
> How about changing to use -f in your scenario ( on RO mounted root
> image
> )?
This was with -f. Without -f it still refuses to open the device.
>>>
>>> What I mean is we'd better to keep line with ext4, just refusing to open
>>> ro
>>> mounted device without -f, since triggering fsck and repair on a mounted
>>> device
>>> is dangerous, it can easily make inconsistency in between in-memory data
>>> and
>>> on-disk data of filesystem. Refusing fsck without -f is to make user
>>> being
>>> aware
>>> of such danger.
>>
>> I am sorry, I've apparently added the -f after my first report. After
>> re-testing it seems that fsck.f2fs is opening the RO partition even
>> without this patch if I use -f. So the part about fsck.f2fs not being
>> able to open RO mounted partition during boot was a user error.
>
> I've sent a patch for your second issue, could you please have a try with
> it?
>
> [PATCH] fsck.f2fs: fix to repair ro mounted device w/ -f
Tested by forcing a sudden_power_off by reset-switch, seems to work.
> But one concern is that, with this patch, not like the fsck.ext4, fsck.f2fs
> won't show any interaction with below reminding word to remind user to
> decide
> repair or not, it may increase the risk of damaging the device.
>
> Do you want to restore lost files into ./lost_found/?
> Do you want to fix this partition? [Y/N]
>
> Jaegeuk, Hagbard,
>
> Any suggestion on this, in current scenario, how about implement:
> 1. fsck.f2fs -f ro_mounted_device: check; show interaction words if there
> is
> corruption;
> 2. fsck.f2fs -f -a ro_moutned_device: check and repair automatically;
I guess that would be ok. Just to mention: Gentoo defaults to "fsck -A
-p" during boot, where I can add the "-f" option by config file. I am
not up to date on what other distros uses for default
options in their fsck command during boot.
> Thanks,
>
>>
>>>
>>> Thanks,
>>>
> Thanks,
>
>> But as far as I can understand it will still only check the fs, not
>> fix
>> it.
>>
>>
>> 2019-04-21 12:27 GMT+02:00, Jaegeuk Kim :
>>
>>>
>>> New version of the patch is:
>>>
>>> From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00
>>> 2001
>>> From: Jaegeuk Kim
>>> Date: Tue, 16 Apr 2019 11:46:31 -0700
>>> Subject: [PATCH] fsck.f2fs: open ro disk if we want to check fs only
>>>
>>> This patch fixes the "open failure" issue on ro disk, reported by
>>> Hagbard.
>>>
>>> "
>>> If I boot with kernel option "ro rootfstype=f2fs
>>> I get the following halfway trough boot:
>>>
>>> * Checking local filesystems ...
>>> Info: Use default preen mode
>>> Info: Mounted device!
>>> Info: Check FS only due to RO
>>> Error: Failed to open the device!
>>> * Filesystems couldn't be fixed
>>> "
>>>
>>> Reported-by: Hagbard Celine
>>> Signed-off-by: Jaegeuk Kim
>>> ---
>>> lib/libf2fs.c | 25 +
>>> 1 file changed, 21 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/lib/libf2fs.c b/lib/libf2fs.c
>>> index d30047f..853e713 100644
>>> --- a/lib/libf2fs.c
>>> +++ b/lib/libf2fs.c
>>> @@ -789,6 +789,15 @@ void get_kernel_uname_version(__u8 *version)
>>> #endif /* APPLE_DARWIN */
>>>
>>> #ifndef ANDROID_WINDOWS_HOST
>>> +static int open_check_fs(char *path, int flag)
>>> +{
>>> + if (c.func != FSCK || c.fix_on || c.auto_fix)
>>> + return -1;
>>> +
>>> + /* allow to open ro */
>>> + return open(path, O_RDONLY | flag);
>>> +}
>>> +
>>> int get_device_info(int i)
>>> {
>>> int32_t fd = 0;
>>> @@ -810,8 +819,11 @@ int get_device_info(int i)
>>> if (c.sparse_mode) {
>>> fd = open(dev->path, O_RDWR | O_CREAT | O_BINARY, 0644);
>>> if (fd < 0) {
>>> - MSG(0, "\tError: Failed to open a sparse
>>> file!\n");
>>> - return -1;
>>> + fd = open_check_fs(dev->path, O_BINARY);
>>> + if (fd < 0) {
>>> + MSG(0, "\tError: Failed to open a
>>> sparse file!\n");
>>> + return -1;
>>> + }
>>> }
>>> }
>>>
>>> @@ -825,10 +837,15 @@ int get
Re: [f2fs-dev] Possible issues with fsck of f2fs root
On 2019/4/22 18:05, Hagbard Celine wrote:
> 2019-04-22 11:26 GMT+02:00, Chao Yu :
>> On 2019/4/22 17:05, Hagbard Celine wrote:
>>> 2019-04-22 9:37 GMT+02:00, Chao Yu :
On 2019/4/22 15:11, Hagbard Celine wrote:
> With this patch the one problem with opening the device in RO mode is
> fixed.
Oops, with default preen mode fsck should not open ro mounted image,
that's
the
rule we keep line with ext4...
How about changing to use -f in your scenario ( on RO mounted root image
)?
>>>
>>> This was with -f. Without -f it still refuses to open the device.
>>
>> What I mean is we'd better to keep line with ext4, just refusing to open ro
>> mounted device without -f, since triggering fsck and repair on a mounted
>> device
>> is dangerous, it can easily make inconsistency in between in-memory data
>> and
>> on-disk data of filesystem. Refusing fsck without -f is to make user being
>> aware
>> of such danger.
>
> I am sorry, I've apparently added the -f after my first report. After
> re-testing it seems that fsck.f2fs is opening the RO partition even
> without this patch if I use -f. So the part about fsck.f2fs not being
> able to open RO mounted partition during boot was a user error.
I've sent a patch for your second issue, could you please have a try with it?
[PATCH] fsck.f2fs: fix to repair ro mounted device w/ -f
But one concern is that, with this patch, not like the fsck.ext4, fsck.f2fs
won't show any interaction with below reminding word to remind user to decide
repair or not, it may increase the risk of damaging the device.
Do you want to restore lost files into ./lost_found/?
Do you want to fix this partition? [Y/N]
Jaegeuk, Hagbard,
Any suggestion on this, in current scenario, how about implement:
1. fsck.f2fs -f ro_mounted_device: check; show interaction words if there is
corruption;
2. fsck.f2fs -f -a ro_moutned_device: check and repair automatically;
Thanks,
>
>>
>> Thanks,
>>
>>>
>>>
Thanks,
> But as far as I can understand it will still only check the fs, not fix
> it.
>
>
> 2019-04-21 12:27 GMT+02:00, Jaegeuk Kim :
>
>>
>> New version of the patch is:
>>
>> From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00 2001
>> From: Jaegeuk Kim
>> Date: Tue, 16 Apr 2019 11:46:31 -0700
>> Subject: [PATCH] fsck.f2fs: open ro disk if we want to check fs only
>>
>> This patch fixes the "open failure" issue on ro disk, reported by
>> Hagbard.
>>
>> "
>> If I boot with kernel option "ro rootfstype=f2fs
>> I get the following halfway trough boot:
>>
>> * Checking local filesystems ...
>> Info: Use default preen mode
>> Info: Mounted device!
>> Info: Check FS only due to RO
>> Error: Failed to open the device!
>> * Filesystems couldn't be fixed
>> "
>>
>> Reported-by: Hagbard Celine
>> Signed-off-by: Jaegeuk Kim
>> ---
>> lib/libf2fs.c | 25 +
>> 1 file changed, 21 insertions(+), 4 deletions(-)
>>
>> diff --git a/lib/libf2fs.c b/lib/libf2fs.c
>> index d30047f..853e713 100644
>> --- a/lib/libf2fs.c
>> +++ b/lib/libf2fs.c
>> @@ -789,6 +789,15 @@ void get_kernel_uname_version(__u8 *version)
>> #endif /* APPLE_DARWIN */
>>
>> #ifndef ANDROID_WINDOWS_HOST
>> +static int open_check_fs(char *path, int flag)
>> +{
>> +if (c.func != FSCK || c.fix_on || c.auto_fix)
>> +return -1;
>> +
>> +/* allow to open ro */
>> +return open(path, O_RDONLY | flag);
>> +}
>> +
>> int get_device_info(int i)
>> {
>> int32_t fd = 0;
>> @@ -810,8 +819,11 @@ int get_device_info(int i)
>> if (c.sparse_mode) {
>> fd = open(dev->path, O_RDWR | O_CREAT | O_BINARY, 0644);
>> if (fd < 0) {
>> -MSG(0, "\tError: Failed to open a sparse
>> file!\n");
>> -return -1;
>> +fd = open_check_fs(dev->path, O_BINARY);
>> +if (fd < 0) {
>> +MSG(0, "\tError: Failed to open a
>> sparse file!\n");
>> +return -1;
>> +}
>> }
>> }
>>
>> @@ -825,10 +837,15 @@ int get_device_info(int i)
>> return -1;
>> }
>>
>> -if (S_ISBLK(stat_buf->st_mode) && !c.force)
>> +if (S_ISBLK(stat_buf->st_mode) && !c.force) {
>> fd = open(dev->path, O_RDWR | O_EXCL);
>> -else
>> +if (fd < 0)
>> +fd = open_check_fs(dev->path, O_EXCL);
>> +} else {
>>
Re: [f2fs-dev] Possible issues with fsck of f2fs root
2019-04-22 11:26 GMT+02:00, Chao Yu :
> On 2019/4/22 17:05, Hagbard Celine wrote:
>> 2019-04-22 9:37 GMT+02:00, Chao Yu :
>>> On 2019/4/22 15:11, Hagbard Celine wrote:
With this patch the one problem with opening the device in RO mode is
fixed.
>>>
>>> Oops, with default preen mode fsck should not open ro mounted image,
>>> that's
>>> the
>>> rule we keep line with ext4...
>>>
>>> How about changing to use -f in your scenario ( on RO mounted root image
>>> )?
>>
>> This was with -f. Without -f it still refuses to open the device.
>
> What I mean is we'd better to keep line with ext4, just refusing to open ro
> mounted device without -f, since triggering fsck and repair on a mounted
> device
> is dangerous, it can easily make inconsistency in between in-memory data
> and
> on-disk data of filesystem. Refusing fsck without -f is to make user being
> aware
> of such danger.
I am sorry, I've apparently added the -f after my first report. After
re-testing it seems that fsck.f2fs is opening the RO partition even
without this patch if I use -f. So the part about fsck.f2fs not being
able to open RO mounted partition during boot was a user error.
>
> Thanks,
>
>>
>>
>>> Thanks,
>>>
But as far as I can understand it will still only check the fs, not fix
it.
2019-04-21 12:27 GMT+02:00, Jaegeuk Kim :
>
> New version of the patch is:
>
> From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00 2001
> From: Jaegeuk Kim
> Date: Tue, 16 Apr 2019 11:46:31 -0700
> Subject: [PATCH] fsck.f2fs: open ro disk if we want to check fs only
>
> This patch fixes the "open failure" issue on ro disk, reported by
> Hagbard.
>
> "
> If I boot with kernel option "ro rootfstype=f2fs
> I get the following halfway trough boot:
>
> * Checking local filesystems ...
> Info: Use default preen mode
> Info: Mounted device!
> Info: Check FS only due to RO
> Error: Failed to open the device!
> * Filesystems couldn't be fixed
> "
>
> Reported-by: Hagbard Celine
> Signed-off-by: Jaegeuk Kim
> ---
> lib/libf2fs.c | 25 +
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/lib/libf2fs.c b/lib/libf2fs.c
> index d30047f..853e713 100644
> --- a/lib/libf2fs.c
> +++ b/lib/libf2fs.c
> @@ -789,6 +789,15 @@ void get_kernel_uname_version(__u8 *version)
> #endif /* APPLE_DARWIN */
>
> #ifndef ANDROID_WINDOWS_HOST
> +static int open_check_fs(char *path, int flag)
> +{
> + if (c.func != FSCK || c.fix_on || c.auto_fix)
> + return -1;
> +
> + /* allow to open ro */
> + return open(path, O_RDONLY | flag);
> +}
> +
> int get_device_info(int i)
> {
> int32_t fd = 0;
> @@ -810,8 +819,11 @@ int get_device_info(int i)
> if (c.sparse_mode) {
> fd = open(dev->path, O_RDWR | O_CREAT | O_BINARY, 0644);
> if (fd < 0) {
> - MSG(0, "\tError: Failed to open a sparse file!\n");
> - return -1;
> + fd = open_check_fs(dev->path, O_BINARY);
> + if (fd < 0) {
> + MSG(0, "\tError: Failed to open a sparse
> file!\n");
> + return -1;
> + }
> }
> }
>
> @@ -825,10 +837,15 @@ int get_device_info(int i)
> return -1;
> }
>
> - if (S_ISBLK(stat_buf->st_mode) && !c.force)
> + if (S_ISBLK(stat_buf->st_mode) && !c.force) {
> fd = open(dev->path, O_RDWR | O_EXCL);
> - else
> + if (fd < 0)
> + fd = open_check_fs(dev->path, O_EXCL);
> + } else {
> fd = open(dev->path, O_RDWR);
> + if (fd < 0)
> + fd = open_check_fs(dev->path, 0);
> + }
> }
> if (fd < 0) {
> MSG(0, "\tError: Failed to open the device!\n");
> --
> 2.19.0.605.g01d371f741-goog
>
>
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
.
>>>
>> .
>>
>
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] Possible issues with fsck of f2fs root
On 2019/4/22 17:05, Hagbard Celine wrote:
> 2019-04-22 9:37 GMT+02:00, Chao Yu :
>> On 2019/4/22 15:11, Hagbard Celine wrote:
>>> With this patch the one problem with opening the device in RO mode is
>>> fixed.
>>
>> Oops, with default preen mode fsck should not open ro mounted image, that's
>> the
>> rule we keep line with ext4...
>>
>> How about changing to use -f in your scenario ( on RO mounted root image )?
>
> This was with -f. Without -f it still refuses to open the device.
What I mean is we'd better to keep line with ext4, just refusing to open ro
mounted device without -f, since triggering fsck and repair on a mounted device
is dangerous, it can easily make inconsistency in between in-memory data and
on-disk data of filesystem. Refusing fsck without -f is to make user being aware
of such danger.
Thanks,
>
>
>> Thanks,
>>
>>> But as far as I can understand it will still only check the fs, not fix
>>> it.
>>>
>>>
>>> 2019-04-21 12:27 GMT+02:00, Jaegeuk Kim :
>>>
New version of the patch is:
From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim
Date: Tue, 16 Apr 2019 11:46:31 -0700
Subject: [PATCH] fsck.f2fs: open ro disk if we want to check fs only
This patch fixes the "open failure" issue on ro disk, reported by
Hagbard.
"
If I boot with kernel option "ro rootfstype=f2fs
I get the following halfway trough boot:
* Checking local filesystems ...
Info: Use default preen mode
Info: Mounted device!
Info: Check FS only due to RO
Error: Failed to open the device!
* Filesystems couldn't be fixed
"
Reported-by: Hagbard Celine
Signed-off-by: Jaegeuk Kim
---
lib/libf2fs.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/lib/libf2fs.c b/lib/libf2fs.c
index d30047f..853e713 100644
--- a/lib/libf2fs.c
+++ b/lib/libf2fs.c
@@ -789,6 +789,15 @@ void get_kernel_uname_version(__u8 *version)
#endif /* APPLE_DARWIN */
#ifndef ANDROID_WINDOWS_HOST
+static int open_check_fs(char *path, int flag)
+{
+ if (c.func != FSCK || c.fix_on || c.auto_fix)
+ return -1;
+
+ /* allow to open ro */
+ return open(path, O_RDONLY | flag);
+}
+
int get_device_info(int i)
{
int32_t fd = 0;
@@ -810,8 +819,11 @@ int get_device_info(int i)
if (c.sparse_mode) {
fd = open(dev->path, O_RDWR | O_CREAT | O_BINARY, 0644);
if (fd < 0) {
- MSG(0, "\tError: Failed to open a sparse file!\n");
- return -1;
+ fd = open_check_fs(dev->path, O_BINARY);
+ if (fd < 0) {
+ MSG(0, "\tError: Failed to open a sparse
file!\n");
+ return -1;
+ }
}
}
@@ -825,10 +837,15 @@ int get_device_info(int i)
return -1;
}
- if (S_ISBLK(stat_buf->st_mode) && !c.force)
+ if (S_ISBLK(stat_buf->st_mode) && !c.force) {
fd = open(dev->path, O_RDWR | O_EXCL);
- else
+ if (fd < 0)
+ fd = open_check_fs(dev->path, O_EXCL);
+ } else {
fd = open(dev->path, O_RDWR);
+ if (fd < 0)
+ fd = open_check_fs(dev->path, 0);
+ }
}
if (fd < 0) {
MSG(0, "\tError: Failed to open the device!\n");
--
2.19.0.605.g01d371f741-goog
>>>
>>>
>>> ___
>>> Linux-f2fs-devel mailing list
>>> Linux-f2fs-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>>> .
>>>
>>
> .
>
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] Possible issues with fsck of f2fs root
2019-04-22 9:37 GMT+02:00, Chao Yu :
> On 2019/4/22 15:11, Hagbard Celine wrote:
>> With this patch the one problem with opening the device in RO mode is
>> fixed.
>
> Oops, with default preen mode fsck should not open ro mounted image, that's
> the
> rule we keep line with ext4...
>
> How about changing to use -f in your scenario ( on RO mounted root image )?
This was with -f. Without -f it still refuses to open the device.
> Thanks,
>
>> But as far as I can understand it will still only check the fs, not fix
>> it.
>>
>>
>> 2019-04-21 12:27 GMT+02:00, Jaegeuk Kim :
>>
>>>
>>> New version of the patch is:
>>>
>>> From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00 2001
>>> From: Jaegeuk Kim
>>> Date: Tue, 16 Apr 2019 11:46:31 -0700
>>> Subject: [PATCH] fsck.f2fs: open ro disk if we want to check fs only
>>>
>>> This patch fixes the "open failure" issue on ro disk, reported by
>>> Hagbard.
>>>
>>> "
>>> If I boot with kernel option "ro rootfstype=f2fs
>>> I get the following halfway trough boot:
>>>
>>> * Checking local filesystems ...
>>> Info: Use default preen mode
>>> Info: Mounted device!
>>> Info: Check FS only due to RO
>>> Error: Failed to open the device!
>>> * Filesystems couldn't be fixed
>>> "
>>>
>>> Reported-by: Hagbard Celine
>>> Signed-off-by: Jaegeuk Kim
>>> ---
>>> lib/libf2fs.c | 25 +
>>> 1 file changed, 21 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/lib/libf2fs.c b/lib/libf2fs.c
>>> index d30047f..853e713 100644
>>> --- a/lib/libf2fs.c
>>> +++ b/lib/libf2fs.c
>>> @@ -789,6 +789,15 @@ void get_kernel_uname_version(__u8 *version)
>>> #endif /* APPLE_DARWIN */
>>>
>>> #ifndef ANDROID_WINDOWS_HOST
>>> +static int open_check_fs(char *path, int flag)
>>> +{
>>> + if (c.func != FSCK || c.fix_on || c.auto_fix)
>>> + return -1;
>>> +
>>> + /* allow to open ro */
>>> + return open(path, O_RDONLY | flag);
>>> +}
>>> +
>>> int get_device_info(int i)
>>> {
>>> int32_t fd = 0;
>>> @@ -810,8 +819,11 @@ int get_device_info(int i)
>>> if (c.sparse_mode) {
>>> fd = open(dev->path, O_RDWR | O_CREAT | O_BINARY, 0644);
>>> if (fd < 0) {
>>> - MSG(0, "\tError: Failed to open a sparse file!\n");
>>> - return -1;
>>> + fd = open_check_fs(dev->path, O_BINARY);
>>> + if (fd < 0) {
>>> + MSG(0, "\tError: Failed to open a sparse
>>> file!\n");
>>> + return -1;
>>> + }
>>> }
>>> }
>>>
>>> @@ -825,10 +837,15 @@ int get_device_info(int i)
>>> return -1;
>>> }
>>>
>>> - if (S_ISBLK(stat_buf->st_mode) && !c.force)
>>> + if (S_ISBLK(stat_buf->st_mode) && !c.force) {
>>> fd = open(dev->path, O_RDWR | O_EXCL);
>>> - else
>>> + if (fd < 0)
>>> + fd = open_check_fs(dev->path, O_EXCL);
>>> + } else {
>>> fd = open(dev->path, O_RDWR);
>>> + if (fd < 0)
>>> + fd = open_check_fs(dev->path, 0);
>>> + }
>>> }
>>> if (fd < 0) {
>>> MSG(0, "\tError: Failed to open the device!\n");
>>> --
>>> 2.19.0.605.g01d371f741-goog
>>>
>>>
>>
>>
>> ___
>> Linux-f2fs-devel mailing list
>> Linux-f2fs-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>> .
>>
>
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] Possible issues with fsck of f2fs root
On 2019/4/22 15:11, Hagbard Celine wrote:
> With this patch the one problem with opening the device in RO mode is fixed.
Oops, with default preen mode fsck should not open ro mounted image, that's the
rule we keep line with ext4...
How about changing to use -f in your scenario ( on RO mounted root image )?
Thanks,
> But as far as I can understand it will still only check the fs, not fix it.
>
>
> 2019-04-21 12:27 GMT+02:00, Jaegeuk Kim :
>
>>
>> New version of the patch is:
>>
>> From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00 2001
>> From: Jaegeuk Kim
>> Date: Tue, 16 Apr 2019 11:46:31 -0700
>> Subject: [PATCH] fsck.f2fs: open ro disk if we want to check fs only
>>
>> This patch fixes the "open failure" issue on ro disk, reported by Hagbard.
>>
>> "
>> If I boot with kernel option "ro rootfstype=f2fs
>> I get the following halfway trough boot:
>>
>> * Checking local filesystems ...
>> Info: Use default preen mode
>> Info: Mounted device!
>> Info: Check FS only due to RO
>> Error: Failed to open the device!
>> * Filesystems couldn't be fixed
>> "
>>
>> Reported-by: Hagbard Celine
>> Signed-off-by: Jaegeuk Kim
>> ---
>> lib/libf2fs.c | 25 +
>> 1 file changed, 21 insertions(+), 4 deletions(-)
>>
>> diff --git a/lib/libf2fs.c b/lib/libf2fs.c
>> index d30047f..853e713 100644
>> --- a/lib/libf2fs.c
>> +++ b/lib/libf2fs.c
>> @@ -789,6 +789,15 @@ void get_kernel_uname_version(__u8 *version)
>> #endif /* APPLE_DARWIN */
>>
>> #ifndef ANDROID_WINDOWS_HOST
>> +static int open_check_fs(char *path, int flag)
>> +{
>> +if (c.func != FSCK || c.fix_on || c.auto_fix)
>> +return -1;
>> +
>> +/* allow to open ro */
>> +return open(path, O_RDONLY | flag);
>> +}
>> +
>> int get_device_info(int i)
>> {
>> int32_t fd = 0;
>> @@ -810,8 +819,11 @@ int get_device_info(int i)
>> if (c.sparse_mode) {
>> fd = open(dev->path, O_RDWR | O_CREAT | O_BINARY, 0644);
>> if (fd < 0) {
>> -MSG(0, "\tError: Failed to open a sparse file!\n");
>> -return -1;
>> +fd = open_check_fs(dev->path, O_BINARY);
>> +if (fd < 0) {
>> +MSG(0, "\tError: Failed to open a sparse
>> file!\n");
>> +return -1;
>> +}
>> }
>> }
>>
>> @@ -825,10 +837,15 @@ int get_device_info(int i)
>> return -1;
>> }
>>
>> -if (S_ISBLK(stat_buf->st_mode) && !c.force)
>> +if (S_ISBLK(stat_buf->st_mode) && !c.force) {
>> fd = open(dev->path, O_RDWR | O_EXCL);
>> -else
>> +if (fd < 0)
>> +fd = open_check_fs(dev->path, O_EXCL);
>> +} else {
>> fd = open(dev->path, O_RDWR);
>> +if (fd < 0)
>> +fd = open_check_fs(dev->path, 0);
>> +}
>> }
>> if (fd < 0) {
>> MSG(0, "\tError: Failed to open the device!\n");
>> --
>> 2.19.0.605.g01d371f741-goog
>>
>>
>
>
> ___
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> .
>
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] Possible issues with fsck of f2fs root
With this patch the one problem with opening the device in RO mode is fixed.
But as far as I can understand it will still only check the fs, not fix it.
2019-04-21 12:27 GMT+02:00, Jaegeuk Kim :
>
> New version of the patch is:
>
> From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00 2001
> From: Jaegeuk Kim
> Date: Tue, 16 Apr 2019 11:46:31 -0700
> Subject: [PATCH] fsck.f2fs: open ro disk if we want to check fs only
>
> This patch fixes the "open failure" issue on ro disk, reported by Hagbard.
>
> "
> If I boot with kernel option "ro rootfstype=f2fs
> I get the following halfway trough boot:
>
> * Checking local filesystems ...
> Info: Use default preen mode
> Info: Mounted device!
> Info: Check FS only due to RO
> Error: Failed to open the device!
> * Filesystems couldn't be fixed
> "
>
> Reported-by: Hagbard Celine
> Signed-off-by: Jaegeuk Kim
> ---
> lib/libf2fs.c | 25 +
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/lib/libf2fs.c b/lib/libf2fs.c
> index d30047f..853e713 100644
> --- a/lib/libf2fs.c
> +++ b/lib/libf2fs.c
> @@ -789,6 +789,15 @@ void get_kernel_uname_version(__u8 *version)
> #endif /* APPLE_DARWIN */
>
> #ifndef ANDROID_WINDOWS_HOST
> +static int open_check_fs(char *path, int flag)
> +{
> + if (c.func != FSCK || c.fix_on || c.auto_fix)
> + return -1;
> +
> + /* allow to open ro */
> + return open(path, O_RDONLY | flag);
> +}
> +
> int get_device_info(int i)
> {
> int32_t fd = 0;
> @@ -810,8 +819,11 @@ int get_device_info(int i)
> if (c.sparse_mode) {
> fd = open(dev->path, O_RDWR | O_CREAT | O_BINARY, 0644);
> if (fd < 0) {
> - MSG(0, "\tError: Failed to open a sparse file!\n");
> - return -1;
> + fd = open_check_fs(dev->path, O_BINARY);
> + if (fd < 0) {
> + MSG(0, "\tError: Failed to open a sparse
> file!\n");
> + return -1;
> + }
> }
> }
>
> @@ -825,10 +837,15 @@ int get_device_info(int i)
> return -1;
> }
>
> - if (S_ISBLK(stat_buf->st_mode) && !c.force)
> + if (S_ISBLK(stat_buf->st_mode) && !c.force) {
> fd = open(dev->path, O_RDWR | O_EXCL);
> - else
> + if (fd < 0)
> + fd = open_check_fs(dev->path, O_EXCL);
> + } else {
> fd = open(dev->path, O_RDWR);
> + if (fd < 0)
> + fd = open_check_fs(dev->path, 0);
> + }
> }
> if (fd < 0) {
> MSG(0, "\tError: Failed to open the device!\n");
> --
> 2.19.0.605.g01d371f741-goog
>
>
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] Possible issues with fsck of f2fs root
On 2019/4/21 18:27, Jaegeuk Kim wrote: > On 04/20, Chao Yu wrote: >> On 2019/4/17 2:53, Jaegeuk Kim wrote: >>> On 04/02, Hagbard Celine wrote: Hi, I lost the root filesystem on my previous install after a few weeks of several power outages last winter. While trying to recover I discovered that it seem fsck was never run properly during boot in the lifetime of that install. After getting the system installed again a while ago, I have been trying to discern why. So far I've found the following two possible issues: ISSUE 1: If I boot with kernel option "ro rootfstype=f2fs rootflags=background_gc=on,heap,disable_ext_identify,discard,user_xattr,inline_xattr,inline_dentry,acl,inline_data,flush_merge,data_flush,extent_cache,whint_mode=fs-based,fsync_mode=strict" I get the following halfway trough boot: * Checking local filesystems ... Info: Use default preen mode Info: Mounted device! Info: Check FS only due to RO Error: Failed to open the device! * Filesystems couldn't be fixed [ !! ] * rc: Aborting! If i from this state try to mount another partition: # mount -o "ro,relatime,lazytime,background_gc=on,discard,heap,user_xattr,inline_xattr,acl,disable_ext_identify,inline_data,inline_dentry,flush_merge,extent_cache,data_flush,mode=adaptive,active_logs=6,whint_mode=fs-based,alloc_mode=default,fsync_mode=strict" /dev/nvme0n1p7 /mnt/f2fstest/ I get the same error if I try to run fsck on it: # fsck.f2fs /dev/nvme0n1p7 Info: Mounted device! Info: Check FS only due to RO Error: Failed to open the device! If I on the other had boot with kernel option "rw rootfstype=f2fs rootflags=background_gc=on,heap,disable_ext_identify,discard,user_xattr,inline_xattr,inline_dentry,acl,inline_data,flush_merge,data_flush,extent_cache,whint_mode=fs-based,fsync_mode=strict panic=30 scsi_mod.use_blk_mq=1" The boot does not hang and if I try same test as before, mount test partition: # mount -o "ro,relatime,lazytime,background_gc=on,discard,heap,user_xattr,inline_xattr,acl,disable_ext_identify,inline_data,inline_dentry,flush_merge,extent_cache,data_flush,mode=adaptive,active_logs=6,whint_mode=fs-based,alloc_mode=default,fsync_mode=strict" /dev/nvme0n1p7 /mnt/f2fstest/ Run fsck: # fsck.f2fs -f /dev/nvme0n1p7 Info: Force to fix corruption Info: Mounted device! Info: Check FS only due to RO Info: Segments per section = 1 Info: Sections per zone = 1 Info: sector size = 512 Info: total sectors = 134101647 (65479 MB) Info: MKFS version "Linux version 5.0.5-gentoof2fsfix (root@40o2) (gcc version 8.2.0 (Gentoo 8.2.0-r6 p1.7)) #2 SMP PREEMPT Mon Apr 1 17:04:41 +01 2019" Info: FSCK version from "Linux version 5.0.5-gentoo (root@40o2) (gcc version 8.2.0 (Gentoo 8.2.0-r6 p1.7)) #2 SMP PREEMPT Tue Apr 2 07:42:40 +01 2019" to "Linux version 5.0.5-gentoo (root@40o2) (gcc version 8.2.0 (Gentoo 8.2.0-r6 p1.7)) #2 SMP PREEMPT Tue Apr 2 07:42:40 +01 2019" Info: superblock features = 0 : Info: superblock encrypt level = 0, salt = Info: total FS sectors = 134101640 (65479 MB) Info: CKPT version = 70e1454a Info: Checked valid nat_bits in checkpoint Info: checkpoint state = 4c1 : large_nat_bitmap nat_bits crc unmount [FSCK] Unreachable nat entries[Ok..] [0x0] [FSCK] SIT valid block bitmap checking[Ok..] [FSCK] Hard link checking for regular file[Ok..] [0x70] [FSCK] valid_block_count matching with CP [Ok..] [0x1fe244] [FSCK] valid_node_count matcing with CP (de lookup) [Ok..] [0x6c487] [FSCK] valid_node_count matcing with CP (nat lookup) [Ok..] [0x6c487] [FSCK] valid_inode_count matched with CP [Ok..] [0x6c362] [FSCK] free segment_count matched with CP [Ok..] [0x6c44] [FSCK] next block offset is free [Ok..] [FSCK] fixing SIT types [FSCK] other corrupted bugs [Ok..] Done. So a system booted with "rw" root can fsck an "ro" filesystem but a system booted with root "ro" can not. ISSUE 2: Referring to the output from the fsck running against a "ro" filesystem, especially this line: Info: Check FS only due to RO As far as i can tell this says that opposed to other filesystems running fsck against a "ro" mounted f2fs partition will never fix any errors. So I tried running fsck against the same partition mounted "rw": # mount -o remount,rw /mnt/f2fstest/ # fsck.f2fs -f /dev/nvme0n1p7 Info: Force to fix corruption Info: Mounted device! Error: Not availab
Re: [f2fs-dev] Possible issues with fsck of f2fs root
Hi Hagbard, On 2019/4/3 3:29, Hagbard Celine wrote: > Hi, I lost the root filesystem on my previous install after a few > weeks of several power outages last winter. While trying to recover I > discovered that it seem fsck was never run properly during boot in the > lifetime of that install. > After getting the system installed again a while ago, I have been > trying to discern why. > So far I've found the following two possible issues: > > ISSUE 1: > If I boot with kernel option "ro rootfstype=f2fs > rootflags=background_gc=on,heap,disable_ext_identify,discard,user_xattr,inline_xattr,inline_dentry,acl,inline_data,flush_merge,data_flush,extent_cache,whint_mode=fs-based,fsync_mode=strict" > I get the following halfway trough boot: > > * Checking local filesystems ... > Info: Use default preen mode > Info: Mounted device! > Info: Check FS only due to RO > Error: Failed to open the device! > * Filesystems couldn't be fixed > > > [ !! ] * rc: Aborting! > > If i from this state try to mount another partition: > # mount -o > "ro,relatime,lazytime,background_gc=on,discard,heap,user_xattr,inline_xattr,acl,disable_ext_identify,inline_data,inline_dentry,flush_merge,extent_cache,data_flush,mode=adaptive,active_logs=6,whint_mode=fs-based,alloc_mode=default,fsync_mode=strict" > /dev/nvme0n1p7 /mnt/f2fstest/ > > I get the same error if I try to run fsck on it: > # fsck.f2fs /dev/nvme0n1p7 > Info: Mounted device! > Info: Check FS only due to RO > Error: Failed to open the device! > > If I on the other had boot with kernel option "rw rootfstype=f2fs > rootflags=background_gc=on,heap,disable_ext_identify,discard,user_xattr,inline_xattr,inline_dentry,acl,inline_data,flush_merge,data_flush,extent_cache,whint_mode=fs-based,fsync_mode=strict > panic=30 scsi_mod.use_blk_mq=1" > > The boot does not hang and if I try same test as before, mount test partition: > # mount -o > "ro,relatime,lazytime,background_gc=on,discard,heap,user_xattr,inline_xattr,acl,disable_ext_identify,inline_data,inline_dentry,flush_merge,extent_cache,data_flush,mode=adaptive,active_logs=6,whint_mode=fs-based,alloc_mode=default,fsync_mode=strict" > /dev/nvme0n1p7 /mnt/f2fstest/ > > Run fsck: > # fsck.f2fs -f /dev/nvme0n1p7 > Info: Force to fix corruption > Info: Mounted device! > Info: Check FS only due to RO > Info: Segments per section = 1 > Info: Sections per zone = 1 > Info: sector size = 512 > Info: total sectors = 134101647 (65479 MB) > Info: MKFS version > "Linux version 5.0.5-gentoof2fsfix (root@40o2) (gcc version 8.2.0 > (Gentoo 8.2.0-r6 p1.7)) #2 SMP PREEMPT Mon Apr 1 17:04:41 +01 2019" > Info: FSCK version > from "Linux version 5.0.5-gentoo (root@40o2) (gcc version 8.2.0 > (Gentoo 8.2.0-r6 p1.7)) #2 SMP PREEMPT Tue Apr 2 07:42:40 +01 2019" > to "Linux version 5.0.5-gentoo (root@40o2) (gcc version 8.2.0 > (Gentoo 8.2.0-r6 p1.7)) #2 SMP PREEMPT Tue Apr 2 07:42:40 +01 2019" > Info: superblock features = 0 : > Info: superblock encrypt level = 0, salt = > Info: total FS sectors = 134101640 (65479 MB) > Info: CKPT version = 70e1454a > Info: Checked valid nat_bits in checkpoint > Info: checkpoint state = 4c1 : large_nat_bitmap nat_bits crc unmount > > [FSCK] Unreachable nat entries[Ok..] [0x0] > [FSCK] SIT valid block bitmap checking[Ok..] > [FSCK] Hard link checking for regular file[Ok..] [0x70] > [FSCK] valid_block_count matching with CP [Ok..] [0x1fe244] > [FSCK] valid_node_count matcing with CP (de lookup) [Ok..] [0x6c487] > [FSCK] valid_node_count matcing with CP (nat lookup) [Ok..] [0x6c487] > [FSCK] valid_inode_count matched with CP [Ok..] [0x6c362] > [FSCK] free segment_count matched with CP [Ok..] [0x6c44] > [FSCK] next block offset is free [Ok..] > [FSCK] fixing SIT types > [FSCK] other corrupted bugs [Ok..] > > Done. > > So a system booted with "rw" root can fsck an "ro" filesystem but a > system booted with root "ro" can not. The behavior is almost the same in between f2fs and ext4: * EXT4: - RW MOUNT: # mount -t ext4 /dev/zram0 /mnt/ext4 # fsck.ext4 /dev/zram0 e2fsck 1.44.4 (18-Aug-2018) /dev/zram0 is mounted. e2fsck: Cannot continue, aborting. # fsck.ext4 -f /dev/zram0 e2fsck 1.44.4 (18-Aug-2018) /dev/zram0 is mounted. e2fsck: Cannot continue, aborting. - RO MOUNT: # mount -t ext4 -o remount,ro /dev/zram0 /mnt/ext4 # fsck.ext4 /dev/zram0 e2fsck 1.44.4 (18-Aug-2018) /dev/zram0 is mounted. e2fsck: Cannot continue, aborting. # fsck.ext4 -f /dev/zram0 e2fsck 1.44.4 (18-Aug-2018) Warning! /dev/zram0 is mounted. Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information Block bitmap differences: +(32768--32896) +(98304--98432) +(163840--163968) +(229376--229504) +(2949
Re: [f2fs-dev] Possible issues with fsck of f2fs root
On 04/20, Chao Yu wrote: > On 2019/4/17 2:53, Jaegeuk Kim wrote: > > On 04/02, Hagbard Celine wrote: > >> Hi, I lost the root filesystem on my previous install after a few > >> weeks of several power outages last winter. While trying to recover I > >> discovered that it seem fsck was never run properly during boot in the > >> lifetime of that install. > >> After getting the system installed again a while ago, I have been > >> trying to discern why. > >> So far I've found the following two possible issues: > >> > >> ISSUE 1: > >> If I boot with kernel option "ro rootfstype=f2fs > >> rootflags=background_gc=on,heap,disable_ext_identify,discard,user_xattr,inline_xattr,inline_dentry,acl,inline_data,flush_merge,data_flush,extent_cache,whint_mode=fs-based,fsync_mode=strict" > >> I get the following halfway trough boot: > >> > >> * Checking local filesystems ... > >> Info: Use default preen mode > >> Info: Mounted device! > >> Info: Check FS only due to RO > >> Error: Failed to open the device! > >> * Filesystems couldn't be fixed > >> > >> > >> [ !! ] * rc: Aborting! > >> > >> If i from this state try to mount another partition: > >> # mount -o > >> "ro,relatime,lazytime,background_gc=on,discard,heap,user_xattr,inline_xattr,acl,disable_ext_identify,inline_data,inline_dentry,flush_merge,extent_cache,data_flush,mode=adaptive,active_logs=6,whint_mode=fs-based,alloc_mode=default,fsync_mode=strict" > >> /dev/nvme0n1p7 /mnt/f2fstest/ > >> > >> I get the same error if I try to run fsck on it: > >> # fsck.f2fs /dev/nvme0n1p7 > >> Info: Mounted device! > >> Info: Check FS only due to RO > >> Error: Failed to open the device! > >> > >> If I on the other had boot with kernel option "rw rootfstype=f2fs > >> rootflags=background_gc=on,heap,disable_ext_identify,discard,user_xattr,inline_xattr,inline_dentry,acl,inline_data,flush_merge,data_flush,extent_cache,whint_mode=fs-based,fsync_mode=strict > >> panic=30 scsi_mod.use_blk_mq=1" > >> > >> The boot does not hang and if I try same test as before, mount test > >> partition: > >> # mount -o > >> "ro,relatime,lazytime,background_gc=on,discard,heap,user_xattr,inline_xattr,acl,disable_ext_identify,inline_data,inline_dentry,flush_merge,extent_cache,data_flush,mode=adaptive,active_logs=6,whint_mode=fs-based,alloc_mode=default,fsync_mode=strict" > >> /dev/nvme0n1p7 /mnt/f2fstest/ > >> > >> Run fsck: > >> # fsck.f2fs -f /dev/nvme0n1p7 > >> Info: Force to fix corruption > >> Info: Mounted device! > >> Info: Check FS only due to RO > >> Info: Segments per section = 1 > >> Info: Sections per zone = 1 > >> Info: sector size = 512 > >> Info: total sectors = 134101647 (65479 MB) > >> Info: MKFS version > >> "Linux version 5.0.5-gentoof2fsfix (root@40o2) (gcc version 8.2.0 > >> (Gentoo 8.2.0-r6 p1.7)) #2 SMP PREEMPT Mon Apr 1 17:04:41 +01 2019" > >> Info: FSCK version > >> from "Linux version 5.0.5-gentoo (root@40o2) (gcc version 8.2.0 > >> (Gentoo 8.2.0-r6 p1.7)) #2 SMP PREEMPT Tue Apr 2 07:42:40 +01 2019" > >> to "Linux version 5.0.5-gentoo (root@40o2) (gcc version 8.2.0 > >> (Gentoo 8.2.0-r6 p1.7)) #2 SMP PREEMPT Tue Apr 2 07:42:40 +01 2019" > >> Info: superblock features = 0 : > >> Info: superblock encrypt level = 0, salt = > >> Info: total FS sectors = 134101640 (65479 MB) > >> Info: CKPT version = 70e1454a > >> Info: Checked valid nat_bits in checkpoint > >> Info: checkpoint state = 4c1 : large_nat_bitmap nat_bits crc unmount > >> > >> [FSCK] Unreachable nat entries[Ok..] [0x0] > >> [FSCK] SIT valid block bitmap checking[Ok..] > >> [FSCK] Hard link checking for regular file[Ok..] [0x70] > >> [FSCK] valid_block_count matching with CP [Ok..] [0x1fe244] > >> [FSCK] valid_node_count matcing with CP (de lookup) [Ok..] [0x6c487] > >> [FSCK] valid_node_count matcing with CP (nat lookup) [Ok..] [0x6c487] > >> [FSCK] valid_inode_count matched with CP [Ok..] [0x6c362] > >> [FSCK] free segment_count matched with CP [Ok..] [0x6c44] > >> [FSCK] next block offset is free [Ok..] > >> [FSCK] fixing SIT types > >> [FSCK] other corrupted bugs [Ok..] > >> > >> Done. > >> > >> So a system booted with "rw" root can fsck an "ro" filesystem but a > >> system booted with root "ro" can not. > >> > >> > >> ISSUE 2: > >> Referring to the output from the fsck running against a "ro" > >> filesystem, especially this line: > >> Info: Check FS only due to RO > >> > >> As far as i can tell this says that opposed to other filesystems > >> running fsck against a "ro" mounted f2fs partition will never fix any > >> errors. > >> So I tried running fsck against the same partition mounted "rw": > >> # mount -o remount,rw /mnt/f2fstest/ > >> # fsck.f2fs -f /dev/nvme0n1p7 > >> Info: Force to fix corruption > >> Info: Mounted device! > >> Error: Not available on mounted device! > >> > >> I might be
Re: [f2fs-dev] Possible issues with fsck of f2fs root
On 2019/4/17 2:53, Jaegeuk Kim wrote: > On 04/02, Hagbard Celine wrote: >> Hi, I lost the root filesystem on my previous install after a few >> weeks of several power outages last winter. While trying to recover I >> discovered that it seem fsck was never run properly during boot in the >> lifetime of that install. >> After getting the system installed again a while ago, I have been >> trying to discern why. >> So far I've found the following two possible issues: >> >> ISSUE 1: >> If I boot with kernel option "ro rootfstype=f2fs >> rootflags=background_gc=on,heap,disable_ext_identify,discard,user_xattr,inline_xattr,inline_dentry,acl,inline_data,flush_merge,data_flush,extent_cache,whint_mode=fs-based,fsync_mode=strict" >> I get the following halfway trough boot: >> >> * Checking local filesystems ... >> Info: Use default preen mode >> Info: Mounted device! >> Info: Check FS only due to RO >> Error: Failed to open the device! >> * Filesystems couldn't be fixed >> >> >> [ !! ] * rc: Aborting! >> >> If i from this state try to mount another partition: >> # mount -o >> "ro,relatime,lazytime,background_gc=on,discard,heap,user_xattr,inline_xattr,acl,disable_ext_identify,inline_data,inline_dentry,flush_merge,extent_cache,data_flush,mode=adaptive,active_logs=6,whint_mode=fs-based,alloc_mode=default,fsync_mode=strict" >> /dev/nvme0n1p7 /mnt/f2fstest/ >> >> I get the same error if I try to run fsck on it: >> # fsck.f2fs /dev/nvme0n1p7 >> Info: Mounted device! >> Info: Check FS only due to RO >> Error: Failed to open the device! >> >> If I on the other had boot with kernel option "rw rootfstype=f2fs >> rootflags=background_gc=on,heap,disable_ext_identify,discard,user_xattr,inline_xattr,inline_dentry,acl,inline_data,flush_merge,data_flush,extent_cache,whint_mode=fs-based,fsync_mode=strict >> panic=30 scsi_mod.use_blk_mq=1" >> >> The boot does not hang and if I try same test as before, mount test >> partition: >> # mount -o >> "ro,relatime,lazytime,background_gc=on,discard,heap,user_xattr,inline_xattr,acl,disable_ext_identify,inline_data,inline_dentry,flush_merge,extent_cache,data_flush,mode=adaptive,active_logs=6,whint_mode=fs-based,alloc_mode=default,fsync_mode=strict" >> /dev/nvme0n1p7 /mnt/f2fstest/ >> >> Run fsck: >> # fsck.f2fs -f /dev/nvme0n1p7 >> Info: Force to fix corruption >> Info: Mounted device! >> Info: Check FS only due to RO >> Info: Segments per section = 1 >> Info: Sections per zone = 1 >> Info: sector size = 512 >> Info: total sectors = 134101647 (65479 MB) >> Info: MKFS version >> "Linux version 5.0.5-gentoof2fsfix (root@40o2) (gcc version 8.2.0 >> (Gentoo 8.2.0-r6 p1.7)) #2 SMP PREEMPT Mon Apr 1 17:04:41 +01 2019" >> Info: FSCK version >> from "Linux version 5.0.5-gentoo (root@40o2) (gcc version 8.2.0 >> (Gentoo 8.2.0-r6 p1.7)) #2 SMP PREEMPT Tue Apr 2 07:42:40 +01 2019" >> to "Linux version 5.0.5-gentoo (root@40o2) (gcc version 8.2.0 >> (Gentoo 8.2.0-r6 p1.7)) #2 SMP PREEMPT Tue Apr 2 07:42:40 +01 2019" >> Info: superblock features = 0 : >> Info: superblock encrypt level = 0, salt = >> Info: total FS sectors = 134101640 (65479 MB) >> Info: CKPT version = 70e1454a >> Info: Checked valid nat_bits in checkpoint >> Info: checkpoint state = 4c1 : large_nat_bitmap nat_bits crc unmount >> >> [FSCK] Unreachable nat entries[Ok..] [0x0] >> [FSCK] SIT valid block bitmap checking[Ok..] >> [FSCK] Hard link checking for regular file[Ok..] [0x70] >> [FSCK] valid_block_count matching with CP [Ok..] [0x1fe244] >> [FSCK] valid_node_count matcing with CP (de lookup) [Ok..] [0x6c487] >> [FSCK] valid_node_count matcing with CP (nat lookup) [Ok..] [0x6c487] >> [FSCK] valid_inode_count matched with CP [Ok..] [0x6c362] >> [FSCK] free segment_count matched with CP [Ok..] [0x6c44] >> [FSCK] next block offset is free [Ok..] >> [FSCK] fixing SIT types >> [FSCK] other corrupted bugs [Ok..] >> >> Done. >> >> So a system booted with "rw" root can fsck an "ro" filesystem but a >> system booted with root "ro" can not. >> >> >> ISSUE 2: >> Referring to the output from the fsck running against a "ro" >> filesystem, especially this line: >> Info: Check FS only due to RO >> >> As far as i can tell this says that opposed to other filesystems >> running fsck against a "ro" mounted f2fs partition will never fix any >> errors. >> So I tried running fsck against the same partition mounted "rw": >> # mount -o remount,rw /mnt/f2fstest/ >> # fsck.f2fs -f /dev/nvme0n1p7 >> Info: Force to fix corruption >> Info: Mounted device! >> Error: Not available on mounted device! >> >> I might be misunderstanding something, but all this tells me that >> unless one make a custom initramfs that runs fsck before root is >> mounted (something no distributions has, as far as I know), fsck will >> never fix an f2fs formatted root
Re: [f2fs-dev] Possible issues with fsck of f2fs root
On 04/02, Hagbard Celine wrote: > Hi, I lost the root filesystem on my previous install after a few > weeks of several power outages last winter. While trying to recover I > discovered that it seem fsck was never run properly during boot in the > lifetime of that install. > After getting the system installed again a while ago, I have been > trying to discern why. > So far I've found the following two possible issues: > > ISSUE 1: > If I boot with kernel option "ro rootfstype=f2fs > rootflags=background_gc=on,heap,disable_ext_identify,discard,user_xattr,inline_xattr,inline_dentry,acl,inline_data,flush_merge,data_flush,extent_cache,whint_mode=fs-based,fsync_mode=strict" > I get the following halfway trough boot: > > * Checking local filesystems ... > Info: Use default preen mode > Info: Mounted device! > Info: Check FS only due to RO > Error: Failed to open the device! > * Filesystems couldn't be fixed > > > [ !! ] * rc: Aborting! > > If i from this state try to mount another partition: > # mount -o > "ro,relatime,lazytime,background_gc=on,discard,heap,user_xattr,inline_xattr,acl,disable_ext_identify,inline_data,inline_dentry,flush_merge,extent_cache,data_flush,mode=adaptive,active_logs=6,whint_mode=fs-based,alloc_mode=default,fsync_mode=strict" > /dev/nvme0n1p7 /mnt/f2fstest/ > > I get the same error if I try to run fsck on it: > # fsck.f2fs /dev/nvme0n1p7 > Info: Mounted device! > Info: Check FS only due to RO > Error: Failed to open the device! > > If I on the other had boot with kernel option "rw rootfstype=f2fs > rootflags=background_gc=on,heap,disable_ext_identify,discard,user_xattr,inline_xattr,inline_dentry,acl,inline_data,flush_merge,data_flush,extent_cache,whint_mode=fs-based,fsync_mode=strict > panic=30 scsi_mod.use_blk_mq=1" > > The boot does not hang and if I try same test as before, mount test partition: > # mount -o > "ro,relatime,lazytime,background_gc=on,discard,heap,user_xattr,inline_xattr,acl,disable_ext_identify,inline_data,inline_dentry,flush_merge,extent_cache,data_flush,mode=adaptive,active_logs=6,whint_mode=fs-based,alloc_mode=default,fsync_mode=strict" > /dev/nvme0n1p7 /mnt/f2fstest/ > > Run fsck: > # fsck.f2fs -f /dev/nvme0n1p7 > Info: Force to fix corruption > Info: Mounted device! > Info: Check FS only due to RO > Info: Segments per section = 1 > Info: Sections per zone = 1 > Info: sector size = 512 > Info: total sectors = 134101647 (65479 MB) > Info: MKFS version > "Linux version 5.0.5-gentoof2fsfix (root@40o2) (gcc version 8.2.0 > (Gentoo 8.2.0-r6 p1.7)) #2 SMP PREEMPT Mon Apr 1 17:04:41 +01 2019" > Info: FSCK version > from "Linux version 5.0.5-gentoo (root@40o2) (gcc version 8.2.0 > (Gentoo 8.2.0-r6 p1.7)) #2 SMP PREEMPT Tue Apr 2 07:42:40 +01 2019" > to "Linux version 5.0.5-gentoo (root@40o2) (gcc version 8.2.0 > (Gentoo 8.2.0-r6 p1.7)) #2 SMP PREEMPT Tue Apr 2 07:42:40 +01 2019" > Info: superblock features = 0 : > Info: superblock encrypt level = 0, salt = > Info: total FS sectors = 134101640 (65479 MB) > Info: CKPT version = 70e1454a > Info: Checked valid nat_bits in checkpoint > Info: checkpoint state = 4c1 : large_nat_bitmap nat_bits crc unmount > > [FSCK] Unreachable nat entries[Ok..] [0x0] > [FSCK] SIT valid block bitmap checking[Ok..] > [FSCK] Hard link checking for regular file[Ok..] [0x70] > [FSCK] valid_block_count matching with CP [Ok..] [0x1fe244] > [FSCK] valid_node_count matcing with CP (de lookup) [Ok..] [0x6c487] > [FSCK] valid_node_count matcing with CP (nat lookup) [Ok..] [0x6c487] > [FSCK] valid_inode_count matched with CP [Ok..] [0x6c362] > [FSCK] free segment_count matched with CP [Ok..] [0x6c44] > [FSCK] next block offset is free [Ok..] > [FSCK] fixing SIT types > [FSCK] other corrupted bugs [Ok..] > > Done. > > So a system booted with "rw" root can fsck an "ro" filesystem but a > system booted with root "ro" can not. > > > ISSUE 2: > Referring to the output from the fsck running against a "ro" > filesystem, especially this line: > Info: Check FS only due to RO > > As far as i can tell this says that opposed to other filesystems > running fsck against a "ro" mounted f2fs partition will never fix any > errors. > So I tried running fsck against the same partition mounted "rw": > # mount -o remount,rw /mnt/f2fstest/ > # fsck.f2fs -f /dev/nvme0n1p7 > Info: Force to fix corruption > Info: Mounted device! > Error: Not available on mounted device! > > I might be misunderstanding something, but all this tells me that > unless one make a custom initramfs that runs fsck before root is > mounted (something no distributions has, as far as I know), fsck will > never fix an f2fs formatted root partition during boot. > If this is by design and not a bug/unintended behavior, it should be > documented somewhere least more peop
