Possible issues with fsck of f2fs root

Possible issues with fsck of f2fs root

[Hagbard Celine]

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 = 00000000000000000000000000000000
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 people will experience system crashes
like mine.

All tests above done with kernel 5.0.5 and f2fs-tools 1.12.0 with
"fsck.f2fs: allow to fsck readonly image w/ -f option"-patch by Chao
Yu.

Re: Possible issues with fsck of f2fs root

[Jaegeuk Kim]

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 = 00000000000000000000000000000000
> 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 people will experience system crashes
> like mine.
> 
> All tests above done with kernel 5.0.5 and f2fs-tools 1.12.0 with
> "fsck.f2fs: allow to fsck readonly image w/ -f option"-patch by Chao
> Yu.

Hi Hagbard,

It looks like fsck.f2fs failed to open a device as RW on RO disk. Could you
try this patch?

Thanks,

>From 3f18ff744f4d510d8e2f42c5a3b2539651baccc5 Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim <jaegeuk@kernel.org>
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 <hagbardcelin@gmail.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
---
 lib/libf2fs.c | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/lib/libf2fs.c b/lib/libf2fs.c
index f8f6921..1a0d179 100644
--- a/lib/libf2fs.c
+++ b/lib/libf2fs.c
@@ -818,9 +818,16 @@ int get_device_info(int i)
 	unsigned char model_inq[6] = {MODELINQUIRY};
 #endif
 	struct device_info *dev = c.devices + i;
+	int rw_flag;
+
+	/* Check FS only */
+	if (c.fix_on == 0 && c.auto_fix == 0)
+		rw_flag = O_RDONLY;
+	else
+		rw_flag = O_RDWR;
 
 	if (c.sparse_mode) {
-		fd = open(dev->path, O_RDWR | O_CREAT | O_BINARY, 0644);
+		fd = open(dev->path, rw_flag | O_CREAT | O_BINARY, 0644);
 		if (fd < 0) {
 			MSG(0, "\tError: Failed to open a sparse file!\n");
 			return -1;
@@ -838,9 +845,9 @@ int get_device_info(int i)
 		}
 
 		if (S_ISBLK(stat_buf->st_mode) && !c.force)
-			fd = open(dev->path, O_RDWR | O_EXCL);
+			fd = open(dev->path, rw_flag | O_EXCL);
 		else
-			fd = open(dev->path, O_RDWR);
+			fd = open(dev->path, rw_flag);
 	}
 	if (fd < 0) {
 		MSG(0, "\tError: Failed to open the device!\n");
-- 
2.19.0.605.g01d371f741-goog

Re: Possible issues with fsck of f2fs root

[Chao Yu]

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 = 00000000000000000000000000000000
>> 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 people will experience system crashes
>> like mine.
>>
>> All tests above done with kernel 5.0.5 and f2fs-tools 1.12.0 with
>> "fsck.f2fs: allow to fsck readonly image w/ -f option"-patch by Chao
>> Yu.
> 
> Hi Hagbard,
> 
> It looks like fsck.f2fs failed to open a device as RW on RO disk. Could you
> try this patch?
> 
> Thanks,
> 
>>From 3f18ff744f4d510d8e2f42c5a3b2539651baccc5 Mon Sep 17 00:00:00 2001
> From: Jaegeuk Kim <jaegeuk@kernel.org>
> 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 <hagbardcelin@gmail.com>
> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> ---
>  lib/libf2fs.c | 13 ++++++++++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/libf2fs.c b/lib/libf2fs.c
> index f8f6921..1a0d179 100644
> --- a/lib/libf2fs.c
> +++ b/lib/libf2fs.c
> @@ -818,9 +818,16 @@ int get_device_info(int i)
>  	unsigned char model_inq[6] = {MODELINQUIRY};
>  #endif
>  	struct device_info *dev = c.devices + i;
> +	int rw_flag;
> +
> +	/* Check FS only */
> +	if (c.fix_on == 0 && c.auto_fix == 0)
> +		rw_flag = O_RDONLY;
> +	else
> +		rw_flag = O_RDWR;
>  
>  	if (c.sparse_mode) {
> -		fd = open(dev->path, O_RDWR | O_CREAT | O_BINARY, 0644);
> +		fd = open(dev->path, rw_flag | O_CREAT | O_BINARY, 0644);
>  		if (fd < 0) {
>  			MSG(0, "\tError: Failed to open a sparse file!\n");
>  			return -1;
> @@ -838,9 +845,9 @@ int get_device_info(int i)
>  		}
>  
>  		if (S_ISBLK(stat_buf->st_mode) && !c.force)
> -			fd = open(dev->path, O_RDWR | O_EXCL);
> +			fd = open(dev->path, rw_flag | O_EXCL);
>  		else
> -			fd = open(dev->path, O_RDWR);
> +			fd = open(dev->path, rw_flag);
>  	}
>  	if (fd < 0) {
>  		MSG(0, "\tError: Failed to open the device!\n");

Jaegeuk,

Last merged patch wasn't sent out..., so I just reply on this old one.

		if (S_ISBLK(stat_buf->st_mode) && !c.force) {

Shouldn't be (.. && c.force) ?

			fd = open(dev->path, O_RDWR | O_EXCL);
			if (fd < 0)
				fd = open_check_fs(dev->path, O_EXCL);

It

		} else {
			fd = open(dev->path, O_RDWR);
			if (fd < 0)
				fd = open_check_fs(dev->path, 0);
		}

> 

Re: Possible issues with fsck of f2fs root

[Jaegeuk Kim]

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 = 00000000000000000000000000000000
> >> 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 people will experience system crashes
> >> like mine.
> >>
> >> All tests above done with kernel 5.0.5 and f2fs-tools 1.12.0 with
> >> "fsck.f2fs: allow to fsck readonly image w/ -f option"-patch by Chao
> >> Yu.
> > 
> > Hi Hagbard,
> > 
> > It looks like fsck.f2fs failed to open a device as RW on RO disk. Could you
> > try this patch?
> > 
> > Thanks,
> > 
> >>From 3f18ff744f4d510d8e2f42c5a3b2539651baccc5 Mon Sep 17 00:00:00 2001
> > From: Jaegeuk Kim <jaegeuk@kernel.org>
> > 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 <hagbardcelin@gmail.com>
> > Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> > ---
> >  lib/libf2fs.c | 13 ++++++++++---
> >  1 file changed, 10 insertions(+), 3 deletions(-)
> > 
> > diff --git a/lib/libf2fs.c b/lib/libf2fs.c
> > index f8f6921..1a0d179 100644
> > --- a/lib/libf2fs.c
> > +++ b/lib/libf2fs.c
> > @@ -818,9 +818,16 @@ int get_device_info(int i)
> >  	unsigned char model_inq[6] = {MODELINQUIRY};
> >  #endif
> >  	struct device_info *dev = c.devices + i;
> > +	int rw_flag;
> > +
> > +	/* Check FS only */
> > +	if (c.fix_on == 0 && c.auto_fix == 0)
> > +		rw_flag = O_RDONLY;
> > +	else
> > +		rw_flag = O_RDWR;
> >  
> >  	if (c.sparse_mode) {
> > -		fd = open(dev->path, O_RDWR | O_CREAT | O_BINARY, 0644);
> > +		fd = open(dev->path, rw_flag | O_CREAT | O_BINARY, 0644);
> >  		if (fd < 0) {
> >  			MSG(0, "\tError: Failed to open a sparse file!\n");
> >  			return -1;
> > @@ -838,9 +845,9 @@ int get_device_info(int i)
> >  		}
> >  
> >  		if (S_ISBLK(stat_buf->st_mode) && !c.force)
> > -			fd = open(dev->path, O_RDWR | O_EXCL);
> > +			fd = open(dev->path, rw_flag | O_EXCL);
> >  		else
> > -			fd = open(dev->path, O_RDWR);
> > +			fd = open(dev->path, rw_flag);
> >  	}
> >  	if (fd < 0) {
> >  		MSG(0, "\tError: Failed to open the device!\n");
> 
> Jaegeuk,
> 
> Last merged patch wasn't sent out..., so I just reply on this old one.
> 
> 		if (S_ISBLK(stat_buf->st_mode) && !c.force) {
> 
> Shouldn't be (.. && c.force) ?

This has nothing to do with this patch tho, it looks good since, in normal case,
we'd better O_EXCL, but in the force mode, we'd like to open the device freely.

New version of the patch is:

>From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim <jaegeuk@kernel.org>
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 <hagbardcelin@gmail.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
---
 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

Re: Possible issues with fsck of f2fs root

[Chao Yu]

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 = 00000000000000000000000000000000
>>>> 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 people will experience system crashes
>>>> like mine.
>>>>
>>>> All tests above done with kernel 5.0.5 and f2fs-tools 1.12.0 with
>>>> "fsck.f2fs: allow to fsck readonly image w/ -f option"-patch by Chao
>>>> Yu.
>>>
>>> Hi Hagbard,
>>>
>>> It looks like fsck.f2fs failed to open a device as RW on RO disk. Could you
>>> try this patch?
>>>
>>> Thanks,
>>>
>>> >From 3f18ff744f4d510d8e2f42c5a3b2539651baccc5 Mon Sep 17 00:00:00 2001
>>> From: Jaegeuk Kim <jaegeuk@kernel.org>
>>> 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 <hagbardcelin@gmail.com>
>>> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>>> ---
>>>  lib/libf2fs.c | 13 ++++++++++---
>>>  1 file changed, 10 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/lib/libf2fs.c b/lib/libf2fs.c
>>> index f8f6921..1a0d179 100644
>>> --- a/lib/libf2fs.c
>>> +++ b/lib/libf2fs.c
>>> @@ -818,9 +818,16 @@ int get_device_info(int i)
>>>  	unsigned char model_inq[6] = {MODELINQUIRY};
>>>  #endif
>>>  	struct device_info *dev = c.devices + i;
>>> +	int rw_flag;
>>> +
>>> +	/* Check FS only */
>>> +	if (c.fix_on == 0 && c.auto_fix == 0)
>>> +		rw_flag = O_RDONLY;
>>> +	else
>>> +		rw_flag = O_RDWR;
>>>  
>>>  	if (c.sparse_mode) {
>>> -		fd = open(dev->path, O_RDWR | O_CREAT | O_BINARY, 0644);
>>> +		fd = open(dev->path, rw_flag | O_CREAT | O_BINARY, 0644);
>>>  		if (fd < 0) {
>>>  			MSG(0, "\tError: Failed to open a sparse file!\n");
>>>  			return -1;
>>> @@ -838,9 +845,9 @@ int get_device_info(int i)
>>>  		}
>>>  
>>>  		if (S_ISBLK(stat_buf->st_mode) && !c.force)
>>> -			fd = open(dev->path, O_RDWR | O_EXCL);
>>> +			fd = open(dev->path, rw_flag | O_EXCL);
>>>  		else
>>> -			fd = open(dev->path, O_RDWR);
>>> +			fd = open(dev->path, rw_flag);
>>>  	}
>>>  	if (fd < 0) {
>>>  		MSG(0, "\tError: Failed to open the device!\n");
>>
>> Jaegeuk,
>>
>> Last merged patch wasn't sent out..., so I just reply on this old one.
>>
>> 		if (S_ISBLK(stat_buf->st_mode) && !c.force) {
>>
>> Shouldn't be (.. && c.force) ?

The point I replied is wrong, please ignore this. :P

> 
> This has nothing to do with this patch tho, it looks good since, in normal case,
> we'd better O_EXCL, but in the force mode, we'd like to open the device freely.
> 
> New version of the patch is:
> 
>>From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00 2001
> From: Jaegeuk Kim <jaegeuk@kernel.org>
> 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

The behavior above is the same as ext4, we don't need to check that.

The different here in between and ext4 and f2fs, is on ro mounted image, ext4
and check and fix issues, but f2fs only do the check, so, that's what Hagbard
complained, since there is no way to repair a ro or rw mounted image with
fsck.f2fs...

Thanks,

> "
> 
> Reported-by: Hagbard Celine <hagbardcelin@gmail.com>
> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> ---
>  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");
> 

Re: Possible issues with fsck of f2fs root

[Hagbard Celine]

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 <jaegeuk@kernel.org>:

>
> New version of the patch is:
>
> From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00 2001
> From: Jaegeuk Kim <jaegeuk@kernel.org>
> 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 <hagbardcelin@gmail.com>
> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
> ---
>  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
>
>

Re: Possible issues with fsck of f2fs root

[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 )?

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 <jaegeuk@kernel.org>:
> 
>>
>> New version of the patch is:
>>
>> From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00 2001
>> From: Jaegeuk Kim <jaegeuk@kernel.org>
>> 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 <hagbardcelin@gmail.com>
>> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>> ---
>>  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: Possible issues with fsck of f2fs root

[Hagbard Celine]

2019-04-22 9:37 GMT+02:00, Chao Yu <yuchao0@huawei.com>:
> 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 <jaegeuk@kernel.org>:
>>
>>>
>>> New version of the patch is:
>>>
>>> From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00 2001
>>> From: Jaegeuk Kim <jaegeuk@kernel.org>
>>> 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 <hagbardcelin@gmail.com>
>>> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>>> ---
>>>  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: Possible issues with fsck of f2fs root

[Chao Yu]

On 2019/4/22 17:05, Hagbard Celine wrote:
> 2019-04-22 9:37 GMT+02:00, Chao Yu <yuchao0@huawei.com>:
>> 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 <jaegeuk@kernel.org>:
>>>
>>>>
>>>> New version of the patch is:
>>>>
>>>> From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00 2001
>>>> From: Jaegeuk Kim <jaegeuk@kernel.org>
>>>> 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 <hagbardcelin@gmail.com>
>>>> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>>>> ---
>>>>  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: Possible issues with fsck of f2fs root

[Hagbard Celine]

2019-04-22 11:26 GMT+02:00, Chao Yu <yuchao0@huawei.com>:
> On 2019/4/22 17:05, Hagbard Celine wrote:
>> 2019-04-22 9:37 GMT+02:00, Chao Yu <yuchao0@huawei.com>:
>>> 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 <jaegeuk@kernel.org>:
>>>>
>>>>>
>>>>> New version of the patch is:
>>>>>
>>>>> From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00 2001
>>>>> From: Jaegeuk Kim <jaegeuk@kernel.org>
>>>>> 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 <hagbardcelin@gmail.com>
>>>>> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>>>>> ---
>>>>>  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: Possible issues with fsck of f2fs root

[Chao Yu]

On 2019/4/22 18:05, Hagbard Celine wrote:
> 2019-04-22 11:26 GMT+02:00, Chao Yu <yuchao0@huawei.com>:
>> On 2019/4/22 17:05, Hagbard Celine wrote:
>>> 2019-04-22 9:37 GMT+02:00, Chao Yu <yuchao0@huawei.com>:
>>>> 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 <jaegeuk@kernel.org>:
>>>>>
>>>>>>
>>>>>> New version of the patch is:
>>>>>>
>>>>>> From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00 2001
>>>>>> From: Jaegeuk Kim <jaegeuk@kernel.org>
>>>>>> 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 <hagbardcelin@gmail.com>
>>>>>> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>>>>>> ---
>>>>>>  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: Possible issues with fsck of f2fs root

[Hagbard Celine]

2019-04-23 4:55 GMT+02:00, Chao Yu <yuchao0@huawei.com>:
> On 2019/4/22 18:05, Hagbard Celine wrote:
>> 2019-04-22 11:26 GMT+02:00, Chao Yu <yuchao0@huawei.com>:
>>> On 2019/4/22 17:05, Hagbard Celine wrote:
>>>> 2019-04-22 9:37 GMT+02:00, Chao Yu <yuchao0@huawei.com>:
>>>>> 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 <jaegeuk@kernel.org>:
>>>>>>
>>>>>>>
>>>>>>> New version of the patch is:
>>>>>>>
>>>>>>> From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00
>>>>>>> 2001
>>>>>>> From: Jaegeuk Kim <jaegeuk@kernel.org>
>>>>>>> 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 <hagbardcelin@gmail.com>
>>>>>>> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>>>>>>> ---
>>>>>>>  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: Possible issues with fsck of f2fs root

[Hagbard Celine]

2019-04-23 13:59 GMT+02:00, Hagbard Celine <hagbardcelin@gmail.com>:
> 2019-04-23 4:55 GMT+02:00, Chao Yu <yuchao0@huawei.com>:
>> On 2019/4/22 18:05, Hagbard Celine wrote:
>>> 2019-04-22 11:26 GMT+02:00, Chao Yu <yuchao0@huawei.com>:
>>>> On 2019/4/22 17:05, Hagbard Celine wrote:
>>>>> 2019-04-22 9:37 GMT+02:00, Chao Yu <yuchao0@huawei.com>:
>>>>>> 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 <jaegeuk@kernel.org>:
>>>>>>>
>>>>>>>>
>>>>>>>> New version of the patch is:
>>>>>>>>
>>>>>>>> From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00
>>>>>>>> 2001
>>>>>>>> From: Jaegeuk Kim <jaegeuk@kernel.org>
>>>>>>>> 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 <hagbardcelin@gmail.com>
>>>>>>>> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>>>>>>>> ---
>>>>>>>>  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: Possible issues with fsck of f2fs root

[Hagbard Celine]

2019-04-23 4:55 GMT+02:00, Chao Yu <yuchao0@huawei.com>:
> On 2019/4/22 18:05, Hagbard Celine wrote:
>> 2019-04-22 11:26 GMT+02:00, Chao Yu <yuchao0@huawei.com>:
>>> On 2019/4/22 17:05, Hagbard Celine wrote:
>>>> 2019-04-22 9:37 GMT+02:00, Chao Yu <yuchao0@huawei.com>:
>>>>> 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 <jaegeuk@kernel.org>:
>>>>>>
>>>>>>>
>>>>>>> New version of the patch is:
>>>>>>>
>>>>>>> From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00
>>>>>>> 2001
>>>>>>> From: Jaegeuk Kim <jaegeuk@kernel.org>
>>>>>>> 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 <hagbardcelin@gmail.com>
>>>>>>> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>>>>>>> ---
>>>>>>>  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: Possible issues with fsck of f2fs root

[Chao Yu]

On 2019/4/24 0:17, Hagbard Celine wrote:
> 2019-04-23 4:55 GMT+02:00, Chao Yu <yuchao0@huawei.com>:
>> On 2019/4/22 18:05, Hagbard Celine wrote:
>>> 2019-04-22 11:26 GMT+02:00, Chao Yu <yuchao0@huawei.com>:
>>>> On 2019/4/22 17:05, Hagbard Celine wrote:
>>>>> 2019-04-22 9:37 GMT+02:00, Chao Yu <yuchao0@huawei.com>:
>>>>>> 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<y>?
/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 <jaegeuk@kernel.org>:
>>>>>>>
>>>>>>>>
>>>>>>>> New version of the patch is:
>>>>>>>>
>>>>>>>> From 3221692b060649378f1f69b898ed85a814af3dbf Mon Sep 17 00:00:00
>>>>>>>> 2001
>>>>>>>> From: Jaegeuk Kim <jaegeuk@kernel.org>
>>>>>>>> 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 <hagbardcelin@gmail.com>
>>>>>>>> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
>>>>>>>> ---
>>>>>>>>  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

[Norbert Lange]

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

[Chao Yu]

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

[Michael Laß]

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

[Chao Yu]

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: Possible issues with fsck of f2fs root

[Chao Yu]

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 = 00000000000000000000000000000000
> 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) +(294912--295040)
Fix<y>?
/dev/zram0: e2fsck canceled.


- F2FS:

- RW MOUNT:
# mount -t f2fs /dev/zram1 /mnt/f2fs/

# fsck.f2fs /dev/zram1
Info: Mounted device!
	Error: Not available on mounted device!

# fsck.f2fs -f /dev/zram1
Info: Force to fix corruption
Info: Mounted device!
	Error: Not available on mounted device!

- RO MOUNT:
# mount -t f2fs -o remount,ro /dev/zram1 /mnt/f2fs/

# fsck.f2fs /dev/zram1
Info: Mounted device!
Info: Check FS only due to RO
	Error: Failed to open the device!

# fsck.f2fs -f /dev/zram1
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 = 4096
Info: total sectors = 524288 (2048 MB)
Info: MKFS version
  "Linux version 4.13.16 (root@szvp000201624) (gcc version 4.8.4 (Ubuntu
4.8.4-2ubuntu1~14.04.4)) #6 SMP Fri Aug 3 14:24:57 CST 2018"
Info: FSCK version
  from "Linux version 4.13.16 (root@szvp000201624) (gcc version 4.8.4 (Ubuntu
4.8.4-2ubuntu1~14.04.4)) #6 SMP Fri Aug 3 14:24:57 CST 2018"
    to "Linux version 4.13.16 (root@szvp000201624) (gcc version 4.8.4 (Ubuntu
4.8.4-2ubuntu1~14.04.4)) #6 SMP Fri Aug 3 14:24:57 CST 2018"
Info: superblock features = 0 :
Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000
Info: total FS sectors = 524288 (2048 MB)
Info: CKPT version = 639bbf66
[ASSERT] (build_nat_area_bitmap:2480)  --> 	Error: ino[0x1] block_addr[0x0] is
invalid

[ASSERT] (build_nat_area_bitmap:2480)  --> 	Error: ino[0x2] block_addr[0x0] is
invalid

Info: checkpoint state = 145 :  trimmed crc compacted_summary unmount

NID[0x1] is unreachable, blkaddr:0x0
NID[0x2] is unreachable, blkaddr:0x0
[FSCK] Unreachable nat entries                        [Fail] [0x2]
[FSCK] SIT valid block bitmap checking                [Ok..]
[FSCK] Hard link checking for regular file            [Ok..] [0x0]
[FSCK] valid_block_count matching with CP             [Ok..] [0x2]
[FSCK] valid_node_count matcing with CP (de lookup)   [Ok..] [0x1]
[FSCK] valid_node_count matcing with CP (nat lookup)  [Ok..] [0x1]
[FSCK] valid_inode_count matched with CP              [Ok..] [0x1]
[FSCK] free segment_count matched with CP             [Ok..] [0x3ed]
[FSCK] next block offset is free                      [Ok..]
[FSCK] fixing SIT types
[FSCK] other corrupted bugs                           [Fail]

Done.


> 
> 
> 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 people will experience system crashes
> like mine.

Hmmm.. that's the only different in between ext4 and f2fs, on a ro mounted
image, fsck.ext4 can not only check and also fix any inconsistency found in that
image, but f2fs can't, we need fix that case. :)

Thanks,

> 
> All tests above done with kernel 5.0.5 and f2fs-tools 1.12.0 with
> "fsck.f2fs: allow to fsck readonly image w/ -f option"-patch by Chao
> Yu.
> 
> 
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> .
>