* Possible issues with fsck of f2fs root @ 2019-04-02 19:29 Hagbard Celine 2019-04-16 18:53 ` Jaegeuk Kim 2019-04-22 2:21 ` Chao Yu 0 siblings, 2 replies; 20+ messages in thread From: Hagbard Celine @ 2019-04-02 19:29 UTC (permalink / raw) To: linux-f2fs-devel 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. ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Possible issues with fsck of f2fs root 2019-04-02 19:29 Possible issues with fsck of f2fs root Hagbard Celine @ 2019-04-16 18:53 ` Jaegeuk Kim 2019-04-20 2:34 ` Chao Yu 2019-04-22 2:21 ` Chao Yu 1 sibling, 1 reply; 20+ messages in thread From: Jaegeuk Kim @ 2019-04-16 18:53 UTC (permalink / raw) To: Hagbard Celine; +Cc: linux-f2fs-devel 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 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: Possible issues with fsck of f2fs root 2019-04-16 18:53 ` Jaegeuk Kim @ 2019-04-20 2:34 ` Chao Yu 2019-04-21 10:27 ` Jaegeuk Kim 0 siblings, 1 reply; 20+ messages in thread From: Chao Yu @ 2019-04-20 2:34 UTC (permalink / raw) To: Jaegeuk Kim, Hagbard Celine; +Cc: linux-f2fs-devel 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); } > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Possible issues with fsck of f2fs root 2019-04-20 2:34 ` Chao Yu @ 2019-04-21 10:27 ` Jaegeuk Kim 2019-04-22 2:33 ` Chao Yu 2019-04-22 7:11 ` Hagbard Celine 0 siblings, 2 replies; 20+ messages in thread From: Jaegeuk Kim @ 2019-04-21 10:27 UTC (permalink / raw) To: Chao Yu; +Cc: linux-f2fs-devel 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 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: Possible issues with fsck of f2fs root 2019-04-21 10:27 ` Jaegeuk Kim @ 2019-04-22 2:33 ` Chao Yu 2019-04-22 7:11 ` Hagbard Celine 1 sibling, 0 replies; 20+ messages in thread From: Chao Yu @ 2019-04-22 2:33 UTC (permalink / raw) To: Jaegeuk Kim; +Cc: linux-f2fs-devel 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"); > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Possible issues with fsck of f2fs root 2019-04-21 10:27 ` Jaegeuk Kim 2019-04-22 2:33 ` Chao Yu @ 2019-04-22 7:11 ` Hagbard Celine 2019-04-22 7:37 ` Chao Yu 1 sibling, 1 reply; 20+ messages in thread From: Hagbard Celine @ 2019-04-22 7:11 UTC (permalink / raw) To: Jaegeuk Kim; +Cc: linux-f2fs-devel 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 > > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Possible issues with fsck of f2fs root 2019-04-22 7:11 ` Hagbard Celine @ 2019-04-22 7:37 ` Chao Yu 2019-04-22 9:05 ` Hagbard Celine 0 siblings, 1 reply; 20+ messages in thread From: Chao Yu @ 2019-04-22 7:37 UTC (permalink / raw) To: Hagbard Celine, Jaegeuk Kim; +Cc: linux-f2fs-devel 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 > . > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Possible issues with fsck of f2fs root 2019-04-22 7:37 ` Chao Yu @ 2019-04-22 9:05 ` Hagbard Celine 2019-04-22 9:26 ` Chao Yu 0 siblings, 1 reply; 20+ messages in thread From: Hagbard Celine @ 2019-04-22 9:05 UTC (permalink / raw) To: Chao Yu; +Cc: linux-f2fs-devel 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 >> . >> > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Possible issues with fsck of f2fs root 2019-04-22 9:05 ` Hagbard Celine @ 2019-04-22 9:26 ` Chao Yu 2019-04-22 10:05 ` Hagbard Celine 0 siblings, 1 reply; 20+ messages in thread From: Chao Yu @ 2019-04-22 9:26 UTC (permalink / raw) To: Hagbard Celine; +Cc: linux-f2fs-devel 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 >>> . >>> >> > . > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Possible issues with fsck of f2fs root 2019-04-22 9:26 ` Chao Yu @ 2019-04-22 10:05 ` Hagbard Celine 2019-04-23 2:55 ` Chao Yu 0 siblings, 1 reply; 20+ messages in thread From: Hagbard Celine @ 2019-04-22 10:05 UTC (permalink / raw) To: Chao Yu; +Cc: linux-f2fs-devel 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 >>>> . >>>> >>> >> . >> > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Possible issues with fsck of f2fs root 2019-04-22 10:05 ` Hagbard Celine @ 2019-04-23 2:55 ` Chao Yu 2019-04-23 11:59 ` Hagbard Celine 2019-04-23 16:17 ` Hagbard Celine 0 siblings, 2 replies; 20+ messages in thread From: Chao Yu @ 2019-04-23 2:55 UTC (permalink / raw) To: Hagbard Celine; +Cc: linux-f2fs-devel 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 >>>>> . >>>>> >>>> >>> . >>> >> > . > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Possible issues with fsck of f2fs root 2019-04-23 2:55 ` Chao Yu @ 2019-04-23 11:59 ` Hagbard Celine 2019-04-23 12:18 ` Hagbard Celine 2019-04-23 16:17 ` Hagbard Celine 1 sibling, 1 reply; 20+ messages in thread From: Hagbard Celine @ 2019-04-23 11:59 UTC (permalink / raw) To: Chao Yu; +Cc: linux-f2fs-devel 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 >>>>>> . >>>>>> >>>>> >>>> . >>>> >>> >> . >> > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Possible issues with fsck of f2fs root 2019-04-23 11:59 ` Hagbard Celine @ 2019-04-23 12:18 ` Hagbard Celine 0 siblings, 0 replies; 20+ messages in thread From: Hagbard Celine @ 2019-04-23 12:18 UTC (permalink / raw) To: Chao Yu; +Cc: linux-f2fs-devel 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 >>>>>>> . >>>>>>> >>>>>> >>>>> . >>>>> >>>> >>> . >>> >> > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Possible issues with fsck of f2fs root 2019-04-23 2:55 ` Chao Yu 2019-04-23 11:59 ` Hagbard Celine @ 2019-04-23 16:17 ` Hagbard Celine 2019-04-24 7:07 ` Chao Yu 1 sibling, 1 reply; 20+ messages in thread From: Hagbard Celine @ 2019-04-23 16:17 UTC (permalink / raw) To: linux-f2fs-devel; +Cc: Jaegeuk Kim 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 >>>>>> . >>>>>> >>>>> >>>> . >>>> >>> >> . >> > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Possible issues with fsck of f2fs root 2019-04-23 16:17 ` Hagbard Celine @ 2019-04-24 7:07 ` Chao Yu 2020-07-24 8:11 ` [f2fs-dev] " Norbert Lange 0 siblings, 1 reply; 20+ messages in thread From: Chao Yu @ 2019-04-24 7:07 UTC (permalink / raw) To: Hagbard Celine, linux-f2fs-devel; +Cc: Jaegeuk Kim 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 >>>>>>> . >>>>>>> >>>>>> >>>>> . >>>>> >>>> >>> . >>> >> > . > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [f2fs-dev] Possible issues with fsck of f2fs root 2019-04-24 7:07 ` Chao Yu @ 2020-07-24 8:11 ` Norbert Lange 2020-07-25 2:06 ` Chao Yu 0 siblings, 1 reply; 20+ messages in thread From: Norbert Lange @ 2020-07-24 8:11 UTC (permalink / raw) To: yuchao0; +Cc: jaegeuk, linux-f2fs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [f2fs-dev] Possible issues with fsck of f2fs root 2020-07-24 8:11 ` [f2fs-dev] " Norbert Lange @ 2020-07-25 2:06 ` Chao Yu 2020-07-27 15:02 ` Michael Laß 0 siblings, 1 reply; 20+ messages in thread From: Chao Yu @ 2020-07-25 2:06 UTC (permalink / raw) To: Norbert Lange; +Cc: jaegeuk, linux-f2fs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [f2fs-dev] Possible issues with fsck of f2fs root 2020-07-25 2:06 ` Chao Yu @ 2020-07-27 15:02 ` Michael Laß 2020-07-31 9:08 ` Chao Yu 0 siblings, 1 reply; 20+ messages in thread From: Michael Laß @ 2020-07-27 15:02 UTC (permalink / raw) To: Chao Yu, Norbert Lange; +Cc: jaegeuk, linux-f2fs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [f2fs-dev] Possible issues with fsck of f2fs root 2020-07-27 15:02 ` Michael Laß @ 2020-07-31 9:08 ` Chao Yu 0 siblings, 0 replies; 20+ messages in thread From: Chao Yu @ 2020-07-31 9:08 UTC (permalink / raw) To: Michael Laß, Norbert Lange; +Cc: jaegeuk, linux-f2fs-devel 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Possible issues with fsck of f2fs root 2019-04-02 19:29 Possible issues with fsck of f2fs root Hagbard Celine 2019-04-16 18:53 ` Jaegeuk Kim @ 2019-04-22 2:21 ` Chao Yu 1 sibling, 0 replies; 20+ messages in thread From: Chao Yu @ 2019-04-22 2:21 UTC (permalink / raw) To: Hagbard Celine, linux-f2fs-devel 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 > . > ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2020-07-31 9:08 UTC | newest] Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-04-02 19:29 Possible issues with fsck of f2fs root Hagbard Celine 2019-04-16 18:53 ` Jaegeuk Kim 2019-04-20 2:34 ` Chao Yu 2019-04-21 10:27 ` Jaegeuk Kim 2019-04-22 2:33 ` Chao Yu 2019-04-22 7:11 ` Hagbard Celine 2019-04-22 7:37 ` Chao Yu 2019-04-22 9:05 ` Hagbard Celine 2019-04-22 9:26 ` Chao Yu 2019-04-22 10:05 ` Hagbard Celine 2019-04-23 2:55 ` Chao Yu 2019-04-23 11:59 ` Hagbard Celine 2019-04-23 12:18 ` Hagbard Celine 2019-04-23 16:17 ` Hagbard Celine 2019-04-24 7:07 ` Chao Yu 2020-07-24 8:11 ` [f2fs-dev] " Norbert Lange 2020-07-25 2:06 ` Chao Yu 2020-07-27 15:02 ` Michael Laß 2020-07-31 9:08 ` Chao Yu 2019-04-22 2:21 ` Chao Yu
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.