On sudden f2fs shutdown, zoned block device status and f2fs current
segment positions in meta data can be inconsistent. When f2fs shutdown
happens before write operations completes, write pointers of zoned block
devices can go further but f2fs meta data keeps current segments at
positions before
To prepare for write pointer consistency check by fsck, add
f2fs_report_zones() helper function which calls REPORT ZONE command to
get write pointer status. The function is added to lib/libf2fs_zoned
which gathers zoned block device related functions.
To check write pointer consistency with f2fs
On sudden f2fs shutdown, zoned block device status and f2fs meta data can be
inconsistent. When f2fs shutdown happens during write operations, write pointers
on the device go forward but the f2fs meta data does not reflect write pointer
progress. This inconsistency will eventually cause "Unaligned
When sudden f2fs shutdown happens on zoned block devices, write
pointers can be inconsistent with valid blocks counts in meta data.
The failure scenario is as follows:
- Just before a sudden shutdown, a new segment in a new zone is selected
for a current segment. Write commands were executed to
To allow fsck to reset a zone with inconsistent write pointer, introduce
a helper function f2fs_reset_zone().
Signed-off-by: Shin'ichiro Kawasaki
---
include/f2fs_fs.h | 1 +
lib/libf2fs_zoned.c | 24
2 files changed, 25 insertions(+)
diff --git a/include/f2fs_fs.h
On Tue, 2019-08-20 at 10:57 -0700, Jaegeuk Kim wrote:
> Hi Shinichiro,
>
> Thank you so much for the contribution.
> BTW, I failed to compile them. Could you please take a look at them one more
> time? :)
Thank you for the care and sorry about the compile failure. I checked compile
pass with
On Tuesday, August 20, 2019 11:01 PM Jaegeuk Kim wrote:
> Hi Chandan,
>
> On 08/20, Theodore Y. Ts'o wrote:
> > On Tue, Aug 20, 2019 at 10:35:29AM +0530, Chandan Rajendra wrote:
> > > Looks like F2FS requires a lot more flexiblity than what can be offered by
> > > read callbacks i.e.
> > >
> > >
Replace arguments for get and set xattr methods, and __vfs_getxattr
and __vfs_setaxtr functions with a reference to the following now
common argument structure:
struct xattr_gs_args {
struct dentry *dentry;
struct inode *inode;
const char *name;
union {
Hi Shinichiro,
Thank you so much for the contribution.
BTW, I failed to compile them. Could you please take a look at them one more
time? :)
Thanks,
On 08/19, Shin'ichiro Kawasaki wrote:
> On sudden f2fs shutdown, zoned block device status and f2fs meta data can be
> inconsistent. When f2fs
On 08/20, Chao Yu wrote:
> On 2019/8/20 4:20, Jaegeuk Kim wrote:
> > On 07/26, Chao Yu wrote:
> >> build_sit_info() allocate all bitmaps for each segment one by one,
> >> it's quite low efficiency, this pach changes to allocate large
> >> continuous memory at a time, and divide it and assign for
Hi Chandan,
On 08/20, Theodore Y. Ts'o wrote:
> On Tue, Aug 20, 2019 at 10:35:29AM +0530, Chandan Rajendra wrote:
> > Looks like F2FS requires a lot more flexiblity than what can be offered by
> > read callbacks i.e.
> >
> > 1. F2FS wants to make use of its own workqueue for decryption, verity
Hi Ted,
On Tue, Aug 20, 2019 at 12:25:10PM -0400, Theodore Y. Ts'o wrote:
> On Tue, Aug 20, 2019 at 01:12:36PM +0800, Gao Xiang wrote:
> > Add a word, I have some little concern about post read procession order
> > a bit as I mentioned before, because I'd like to move common EROFS
> >
On Tue, Aug 20, 2019 at 10:35:29AM +0530, Chandan Rajendra wrote:
> Looks like F2FS requires a lot more flexiblity than what can be offered by
> read callbacks i.e.
>
> 1. F2FS wants to make use of its own workqueue for decryption, verity and
>decompression.
> 2. F2FS' decompression code is
On Tue, Aug 20, 2019 at 01:12:36PM +0800, Gao Xiang wrote:
> Add a word, I have some little concern about post read procession order
> a bit as I mentioned before, because I'd like to move common EROFS
> decompression code out in the future as well for other fses to use
> after we think it's
Replace arguments for get and set xattr methods, and __vfs_getxattr
and __vfs_setaxtr functions with a reference to the following now
common argument structure:
struct xattr_gs_args {
struct dentry *dentry;
struct inode *inode;
const char *name;
union {
From: Chao Yu
- f2fs_setattr
- truncate_setsize (expand i_size)
- f2fs_convert_inline_inode
- f2fs_convert_inline_page
- f2fs_reserve_block
- f2fs_get_node_info failed
Once we fail in above path, inline flag will remain, however
- we've reserved one block at inode.i_addr[0]
-
Jaegeuk,
Could you merge [2,3,4/4] patch as well, I just hit one case with por_fsstress.
[ASSERT] (fsck_chk_inode_blk: 803) --> [0x1ec84] wrong inline size:149820
Thanks,
On 2019/8/16 9:20, Chao Yu wrote:
> On 2019/8/16 9:06, Jaegeuk Kim wrote:
>> On 08/12, Chao Yu wrote:
>>> We should always
On Sun, 2019-08-18 at 09:57 -0700, Deepa Dinamani wrote:
> The series is an update and a more complete version of the
> previously posted series at
> https://lore.kernel.org/linux-fsdevel/20180122020426.2988-1-deepa.ker...@gmail.com/
>
> Thanks to Arnd Bergmann for doing a few preliminary
On 2019/8/20 9:00, Jaegeuk Kim wrote:
> On 08/19, Chao Yu wrote:
>> On 2019/8/16 11:03, Chao Yu wrote:
>>> There is one case can cause data corruption.
>>>
>>> - write 4k to fileA
>>> - fsync fileA, 4k data is writebacked to lbaA
>>> - write 4k to fileA
>>> - kworker flushs 4k to lbaB; dnode
On 2019/8/20 9:16, Jaegeuk Kim wrote:
> On 08/18, Chao Yu wrote:
>> On 2019-8-17 9:03, Jaegeuk Kim wrote:
>>> If we use later kernel having larger extra_isize, old fsck will delete
>>> entire old files.
>>
>> Would it be better to construct the length based on existed features?
>
> We can't judge
On 2019/8/20 4:20, Jaegeuk Kim wrote:
> On 07/26, Chao Yu wrote:
>> build_sit_info() allocate all bitmaps for each segment one by one,
>> it's quite low efficiency, this pach changes to allocate large
>> continuous memory at a time, and divide it and assign for each bitmaps
>> of segment. For
On 2019/8/19 21:33, Chandan Rajendra wrote:
> On Sunday, August 18, 2019 7:15:42 PM IST Chao Yu wrote:
>> Hi Chandan,
>>
>> On 2019-8-16 14:18, Chandan Rajendra wrote:
>>> F2FS has a copy of "post read processing" code using which encrypted
>>> file data is decrypted. This commit replaces it to
22 matches
Mail list logo
