Re: [f2fs-dev] [PATCH v4] f2fs: introduce fragment allocation mode mount option
On 2021/9/21 6:57, Jaegeuk Kim wrote: On 09/12, Chao Yu wrote: On 2021/9/11 7:13, Jaegeuk Kim wrote: Wait. Why do we need to add so many options here? I was expecting to see performance difference when getting random segments or random blocks as an extreme case. I don't get the point why we need the middle of those cases. I guess we can simply the aging test procedure of filesystem by changing a bit based on this patch. My question was on "fragment:fixed_block". This mode can be used for below filesystem aging scenario. Fragmenting filesystem with specified pattern: 1M chunk | 1M hole | 1M chunk | 1M hole | ... e.g. Before 1. create/write 10 1M files: file0 file1 file2 ... file9 2. remove file1 file3 file5 ... file9 After mode=fragment:fixed_block fragment_chunk_size=1M fragment_hole_size=1M 1. create/write one 10M file Thanks, See comments in below thread. https://lore.kernel.org/lkml/425daf77-8020-26ce-dc9f-019d9a881...@kernel.org/ Thanks, ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v4] f2fs: introduce fragment allocation mode mount option
On 09/12, Chao Yu wrote: > On 2021/9/11 7:13, Jaegeuk Kim wrote: > > Wait. Why do we need to add so many options here? I was expecting to see > > performance difference when getting random segments or random blocks as > > an extreme case. I don't get the point why we need the middle of those > > cases. > > I guess we can simply the aging test procedure of filesystem by changing a bit > based on this patch. My question was on "fragment:fixed_block". > > See comments in below thread. > > https://lore.kernel.org/lkml/425daf77-8020-26ce-dc9f-019d9a881...@kernel.org/ > > Thanks, ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v4] f2fs: introduce fragment allocation mode mount option
On 2021/9/11 7:13, Jaegeuk Kim wrote: Wait. Why do we need to add so many options here? I was expecting to see performance difference when getting random segments or random blocks as an extreme case. I don't get the point why we need the middle of those cases. I guess we can simply the aging test procedure of filesystem by changing a bit based on this patch. See comments in below thread. https://lore.kernel.org/lkml/425daf77-8020-26ce-dc9f-019d9a881...@kernel.org/ Thanks, ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v4] f2fs: introduce fragment allocation mode mount option
On 2021/9/10 23:24, Daeho Jeong wrote: On Fri, Sep 10, 2021 at 7:34 AM Daeho Jeong wrote: On Thu, Sep 9, 2021 at 4:50 PM Chao Yu wrote: On 2021/9/8 2:12, Daeho Jeong wrote: On Fri, Sep 3, 2021 at 11:45 PM Chao Yu wrote: On 2021/9/4 12:40, Daeho Jeong wrote: As a per curseg field. Maybe, we run into the same race condition issue you told before for fragment_remained_chunk. Could you clarify this more? e.g. F2FS_OPTION(sbi).fs_mode = FS_MODE_FRAGMENT_FIXED_BLK fragment_chunk_size = 384 fragment_hole_size = 384 When creating hole: - f2fs_allocate_data_block - __refresh_next_blkoff chunk locates in [0, 383] of current segment seg->next_blkoff = 384 sbi->fragment_remained_chunk = 0 then we will reset sbi->fragment_remained_chunk to 384 and move seg->next_blkoff forward to 768 (384 + 384) - __has_curseg_space() returns false - allocate_segment() allocates new current segment So, for such case that hole may cross two segments, hole size may be truncated to left size of previous segment. First, sbi->fragment_remained_chunk should be seg->fragment_remained_chunk. Oh, correct. I understand what you mean, so you mean we need to take the leftover "hole" size over to the next segment? In the example, the leftover hole size will be (384 - (512-384)). Do you want to take this over to the next segment? Yes, the left 256 block-sized hole should be created before next chunk in next opened segment. Chao, Do you have any decent idea to pass the left hole size to the next segment which will be allocated? Daeho, I guess we can record left hole size in seg->fragment_remained_hole. I understand we need a new fragment_remained_hole variable in segment structure. But, I mean.. How can we pass over the left hole size from the previous segment to the next segment? I mean we don't know which segment will be the next segment, do we? Yeah, that's why I prefer to let __get_next_segno() return zero in fixed_block fragment mode, then log header may have chance to allocate hole in contiguous segments. Thanks, Thanks, Thanks, Thanks, Thanks, ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v4] f2fs: introduce fragment allocation mode mount option
On 09/02, Daeho Jeong wrote: > From: Daeho Jeong > > Added three options into "mode=" mount option to make it possible for > developers to make the filesystem fragmented or simulate filesystem > fragmentation/after-GC situation itself. The developers use these modes > to understand filesystem fragmentation/after-GC condition well, > and eventually get some insights to handle them better. > > "fragment:segment": f2fs allocates a new segment in ramdom position. > With this, we can simulate the after-GC condition. > "fragment:fixed_block" : We can scatter block allocation with > "fragment_chunk_size" and "fragment_hole_size" sysfs > nodes. f2fs will allocate blocks > in a chunk and make a hole in the length of >by turns in a newly allocated free > segment. Wait. Why do we need to add so many options here? I was expecting to see performance difference when getting random segments or random blocks as an extreme case. I don't get the point why we need the middle of those cases. > "fragment:rand_block" : Working like "fragment:fixed_block" mode, but > added some randomness to both chunk and hole size. So, > f2fs will allocate 1.. blocks in a > chunk and make a hole in the nodes. f2fs will allocate > 1.. blocks in a chunk and make a > hole in the length of 1.. by turns > in a newly allocated free segment. > Plus, f2fs implicitly enables "fragment:segment" option > for more randomness in allocation in "fragment:rand_block". > > Signed-off-by: Daeho Jeong > --- > v4: implicitly enabled "fragment:segment" option only in > "fragment:rand_block". > v3: divided "fragment:block" mode and fixed a race condition related to > making chunks. > v2: changed mode name and added sysfs nodes to control the fragmentation > pattern. > --- > Documentation/ABI/testing/sysfs-fs-f2fs | 24 > Documentation/filesystems/f2fs.rst | 22 +++ > fs/f2fs/f2fs.h | 20 +++-- > fs/f2fs/gc.c| 5 - > fs/f2fs/segment.c | 29 +++-- > fs/f2fs/segment.h | 1 + > fs/f2fs/super.c | 14 > fs/f2fs/sysfs.c | 20 + > 8 files changed, 130 insertions(+), 5 deletions(-) > > diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs > b/Documentation/ABI/testing/sysfs-fs-f2fs > index f627e705e663..d56ecfd16abf 100644 > --- a/Documentation/ABI/testing/sysfs-fs-f2fs > +++ b/Documentation/ABI/testing/sysfs-fs-f2fs > @@ -512,3 +512,27 @@ Date:July 2021 > Contact: "Daeho Jeong" > Description: You can control the multiplier value of bdi device readahead > window size > between 2 (default) and 256 for POSIX_FADV_SEQUENTIAL advise > option. > + > +What:/sys/fs/f2fs//fragment_chunk_size > +Date:August 2021 > +Contact: "Daeho Jeong" > +Description: With "mode=fragment:fixed_block" and "mode=fragment:rand_block" > mount options, > + we can scatter block allocation. Using this node, in > "fragment:fixed_block" > + mode, f2fs will allocate blocks in a > chunk and make > + a hole in the length of by turns in a > newly allocated > + free segment. Plus, in "fragment:rand_block" mode, f2fs will > allocate > + 1.. blocks in a chunk and make a hole in > the length of > + 1.. by turns. This value can be set between > 1..512 and > + the default value is 4. > + > +What:/sys/fs/f2fs//fragment_hole_size > +Date:August 2021 > +Contact: "Daeho Jeong" > +Description: With "mode=fragment:fixed_block" and "mode=fragment:rand_block" > mount options, > + we can scatter block allocation. Using this node, in > "fragment:fixed_block" > + mode, f2fs will allocate blocks in a > chunk and make > + a hole in the length of by turns in a > newly allocated > + free segment. Plus, in "fragment:rand_block" mode, f2fs will > allocate > + 1.. blocks in a chunk and make a hole in > the length of > + 1.. by turns. This value can be set between > 1..512 and > + the default value is 4. > diff --git a/Documentation/filesystems/f2fs.rst > b/Documentation/filesystems/f2fs.rst > index 09de6ebbbdfa..04ddae8754cc 100644 > --- a/Documentation/filesystems/f2fs.rst > +++ b/Documentation/filesystems/f2fs.rst > @@ -201,6 +201,28 @@ fault_type=%d Support configuring fault > injection type, should be > mode=%s Control block allocation mode which supports > "adaptive" >and "lfs". In "lfs" mode, there should be no r
Re: [f2fs-dev] [PATCH v4] f2fs: introduce fragment allocation mode mount option
On Fri, Sep 10, 2021 at 7:34 AM Daeho Jeong wrote: > > On Thu, Sep 9, 2021 at 4:50 PM Chao Yu wrote: > > > > On 2021/9/8 2:12, Daeho Jeong wrote: > > > On Fri, Sep 3, 2021 at 11:45 PM Chao Yu wrote: > > >> > > >> On 2021/9/4 12:40, Daeho Jeong wrote: > > As a per curseg field. > > > > > Maybe, we run into the same race condition issue you told before for > > > fragment_remained_chunk. > > > Could you clarify this more? > > > > e.g. > > > > F2FS_OPTION(sbi).fs_mode = FS_MODE_FRAGMENT_FIXED_BLK > > fragment_chunk_size = 384 > > fragment_hole_size = 384 > > > > When creating hole: > > > > - f2fs_allocate_data_block > > - __refresh_next_blkoff > > chunk locates in [0, 383] of current segment > > seg->next_blkoff = 384 > > sbi->fragment_remained_chunk = 0 > > then we will reset sbi->fragment_remained_chunk to 384 > > and move seg->next_blkoff forward to 768 (384 + 384) > > - __has_curseg_space() returns false > > - allocate_segment() allocates new current segment > > > > So, for such case that hole may cross two segments, hole size may be > > truncated > > to left size of previous segment. > > >>> > > >>> First, sbi->fragment_remained_chunk should be > > >>> seg->fragment_remained_chunk. > > >> > > >> Oh, correct. > > >> > > >>> I understand what you mean, so you mean we need to take the leftover > > >>> "hole" size over to the next segment? > > >>> In the example, the leftover hole size will be (384 - (512-384)). Do > > >>> you want to take this over to the next segment? > > >> > > >> Yes, the left 256 block-sized hole should be created before next chunk > > >> in next opened segment. > > >> > > > > > > Chao, > > > > > > Do you have any decent idea to pass the left hole size to the next > > > segment which will be allocated? > > > > Daeho, > > > > I guess we can record left hole size in seg->fragment_remained_hole. > > > > I understand we need a new fragment_remained_hole variable in segment > structure. > But, I mean.. How can we pass over the left hole size from the > previous segment to the next segment? > I mean we don't know which segment will be the next segment, do we? > Thanks, > > > Thanks, > > > > > > > > Thanks, > > > > > >> Thanks, > > >> > > >>> ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v4] f2fs: introduce fragment allocation mode mount option
On Thu, Sep 9, 2021 at 4:50 PM Chao Yu wrote: > > On 2021/9/8 2:12, Daeho Jeong wrote: > > On Fri, Sep 3, 2021 at 11:45 PM Chao Yu wrote: > >> > >> On 2021/9/4 12:40, Daeho Jeong wrote: > As a per curseg field. > > > Maybe, we run into the same race condition issue you told before for > > fragment_remained_chunk. > > Could you clarify this more? > > e.g. > > F2FS_OPTION(sbi).fs_mode = FS_MODE_FRAGMENT_FIXED_BLK > fragment_chunk_size = 384 > fragment_hole_size = 384 > > When creating hole: > > - f2fs_allocate_data_block > - __refresh_next_blkoff > chunk locates in [0, 383] of current segment > seg->next_blkoff = 384 > sbi->fragment_remained_chunk = 0 > then we will reset sbi->fragment_remained_chunk to 384 > and move seg->next_blkoff forward to 768 (384 + 384) > - __has_curseg_space() returns false > - allocate_segment() allocates new current segment > > So, for such case that hole may cross two segments, hole size may be > truncated > to left size of previous segment. > >>> > >>> First, sbi->fragment_remained_chunk should be > >>> seg->fragment_remained_chunk. > >> > >> Oh, correct. > >> > >>> I understand what you mean, so you mean we need to take the leftover > >>> "hole" size over to the next segment? > >>> In the example, the leftover hole size will be (384 - (512-384)). Do > >>> you want to take this over to the next segment? > >> > >> Yes, the left 256 block-sized hole should be created before next chunk > >> in next opened segment. > >> > > > > Chao, > > > > Do you have any decent idea to pass the left hole size to the next > > segment which will be allocated? > > Daeho, > > I guess we can record left hole size in seg->fragment_remained_hole. > I understand we need a new fragment_remained_hole variable in segment structure. But, I mean.. How can we pass over the left hole size from the previous segment to the next segment? Thanks, > Thanks, > > > > > Thanks, > > > >> Thanks, > >> > >>> ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v4] f2fs: introduce fragment allocation mode mount option
On 2021/9/8 2:12, Daeho Jeong wrote: On Fri, Sep 3, 2021 at 11:45 PM Chao Yu wrote: On 2021/9/4 12:40, Daeho Jeong wrote: As a per curseg field. Maybe, we run into the same race condition issue you told before for fragment_remained_chunk. Could you clarify this more? e.g. F2FS_OPTION(sbi).fs_mode = FS_MODE_FRAGMENT_FIXED_BLK fragment_chunk_size = 384 fragment_hole_size = 384 When creating hole: - f2fs_allocate_data_block - __refresh_next_blkoff chunk locates in [0, 383] of current segment seg->next_blkoff = 384 sbi->fragment_remained_chunk = 0 then we will reset sbi->fragment_remained_chunk to 384 and move seg->next_blkoff forward to 768 (384 + 384) - __has_curseg_space() returns false - allocate_segment() allocates new current segment So, for such case that hole may cross two segments, hole size may be truncated to left size of previous segment. First, sbi->fragment_remained_chunk should be seg->fragment_remained_chunk. Oh, correct. I understand what you mean, so you mean we need to take the leftover "hole" size over to the next segment? In the example, the leftover hole size will be (384 - (512-384)). Do you want to take this over to the next segment? Yes, the left 256 block-sized hole should be created before next chunk in next opened segment. Chao, Do you have any decent idea to pass the left hole size to the next segment which will be allocated? Daeho, I guess we can record left hole size in seg->fragment_remained_hole. Thanks, Thanks, Thanks, ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v4] f2fs: introduce fragment allocation mode mount option
On Fri, Sep 3, 2021 at 11:45 PM Chao Yu wrote: > > On 2021/9/4 12:40, Daeho Jeong wrote: > >> As a per curseg field. > >> > >>> Maybe, we run into the same race condition issue you told before for > >>> fragment_remained_chunk. > >>> Could you clarify this more? > >> > >> e.g. > >> > >> F2FS_OPTION(sbi).fs_mode = FS_MODE_FRAGMENT_FIXED_BLK > >> fragment_chunk_size = 384 > >> fragment_hole_size = 384 > >> > >> When creating hole: > >> > >> - f2fs_allocate_data_block > >>- __refresh_next_blkoff > >> chunk locates in [0, 383] of current segment > >> seg->next_blkoff = 384 > >> sbi->fragment_remained_chunk = 0 > >> then we will reset sbi->fragment_remained_chunk to 384 > >> and move seg->next_blkoff forward to 768 (384 + 384) > >>- __has_curseg_space() returns false > >>- allocate_segment() allocates new current segment > >> > >> So, for such case that hole may cross two segments, hole size may be > >> truncated > >> to left size of previous segment. > > > > First, sbi->fragment_remained_chunk should be seg->fragment_remained_chunk. > > Oh, correct. > > > I understand what you mean, so you mean we need to take the leftover > > "hole" size over to the next segment? > > In the example, the leftover hole size will be (384 - (512-384)). Do > > you want to take this over to the next segment? > > Yes, the left 256 block-sized hole should be created before next chunk > in next opened segment. > Chao, Do you have any decent idea to pass the left hole size to the next segment which will be allocated? Thanks, > Thanks, > > > ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v4] f2fs: introduce fragment allocation mode mount option
On 2021/9/4 12:40, Daeho Jeong wrote: As a per curseg field. Maybe, we run into the same race condition issue you told before for fragment_remained_chunk. Could you clarify this more? e.g. F2FS_OPTION(sbi).fs_mode = FS_MODE_FRAGMENT_FIXED_BLK fragment_chunk_size = 384 fragment_hole_size = 384 When creating hole: - f2fs_allocate_data_block - __refresh_next_blkoff chunk locates in [0, 383] of current segment seg->next_blkoff = 384 sbi->fragment_remained_chunk = 0 then we will reset sbi->fragment_remained_chunk to 384 and move seg->next_blkoff forward to 768 (384 + 384) - __has_curseg_space() returns false - allocate_segment() allocates new current segment So, for such case that hole may cross two segments, hole size may be truncated to left size of previous segment. First, sbi->fragment_remained_chunk should be seg->fragment_remained_chunk. Oh, correct. I understand what you mean, so you mean we need to take the leftover "hole" size over to the next segment? In the example, the leftover hole size will be (384 - (512-384)). Do you want to take this over to the next segment? Yes, the left 256 block-sized hole should be created before next chunk in next opened segment. Thanks, ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v4] f2fs: introduce fragment allocation mode mount option
> As a per curseg field. > > > Maybe, we run into the same race condition issue you told before for > > fragment_remained_chunk. > > Could you clarify this more? > > e.g. > > F2FS_OPTION(sbi).fs_mode = FS_MODE_FRAGMENT_FIXED_BLK > fragment_chunk_size = 384 > fragment_hole_size = 384 > > When creating hole: > > - f2fs_allocate_data_block > - __refresh_next_blkoff > chunk locates in [0, 383] of current segment > seg->next_blkoff = 384 > sbi->fragment_remained_chunk = 0 > then we will reset sbi->fragment_remained_chunk to 384 > and move seg->next_blkoff forward to 768 (384 + 384) > - __has_curseg_space() returns false > - allocate_segment() allocates new current segment > > So, for such case that hole may cross two segments, hole size may be truncated > to left size of previous segment. First, sbi->fragment_remained_chunk should be seg->fragment_remained_chunk. I understand what you mean, so you mean we need to take the leftover "hole" size over to the next segment? In the example, the leftover hole size will be (384 - (512-384)). Do you want to take this over to the next segment? ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v4] f2fs: introduce fragment allocation mode mount option
On 2021/9/4 4:33, Daeho Jeong wrote:
if (f2fs_need_seq_seg(sbi))
return 0;
static inline bool f2fs_need_seq_seg(struct f2fs_sb_info *sbi)
{
return F2FS_OPTION(sbi).fs_mode == FS_MODE_FRAGMENT_FIXED_BLK;
}
Do you need this in select_policy(), either?
IMO, for this mode, I prefer to disable background GC and just use newly
written userdata to fragment image, so I think it's fine to keep it as it is
here.
Like,
if (f2fs_need_rand_seg(sbi))
p->offset = prandom_u32() % (MAIN_SECS(sbi) *
sbi->segs_per_sec);
else if (f2fs_need_seq_seg(sbi))
p->offset = 0;
One more concern... we'd better to save fragment_remained_hole as well
as fragment_remained_chunk, otherwise, if fragment_chunk_size +
fragment_hole_size > 512, fragment hole will be truncated to 512 -
fragment_chunk_size due to we won't create hole with enough size as
seg->next_blkoff has crossed end of current segment.
Sorry, I don't get it. You mean making fragment_remained_hole as a
global variable?
As a per curseg field.
Maybe, we run into the same race condition issue you told before for
fragment_remained_chunk.
Could you clarify this more?
e.g.
F2FS_OPTION(sbi).fs_mode = FS_MODE_FRAGMENT_FIXED_BLK
fragment_chunk_size = 384
fragment_hole_size = 384
When creating hole:
- f2fs_allocate_data_block
- __refresh_next_blkoff
chunk locates in [0, 383] of current segment
seg->next_blkoff = 384
sbi->fragment_remained_chunk = 0
then we will reset sbi->fragment_remained_chunk to 384
and move seg->next_blkoff forward to 768 (384 + 384)
- __has_curseg_space() returns false
- allocate_segment() allocates new current segment
So, for such case that hole may cross two segments, hole size may be truncated
to left size of previous segment.
Thanks,
Thanks,
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v4] f2fs: introduce fragment allocation mode mount option
> if (f2fs_need_seq_seg(sbi))
> return 0;
>
> static inline bool f2fs_need_seq_seg(struct f2fs_sb_info *sbi)
> {
> return F2FS_OPTION(sbi).fs_mode == FS_MODE_FRAGMENT_FIXED_BLK;
> }
>
Do you need this in select_policy(), either?
Like,
if (f2fs_need_rand_seg(sbi))
p->offset = prandom_u32() % (MAIN_SECS(sbi) *
sbi->segs_per_sec);
else if (f2fs_need_seq_seg(sbi))
p->offset = 0;
> One more concern... we'd better to save fragment_remained_hole as well
> as fragment_remained_chunk, otherwise, if fragment_chunk_size +
> fragment_hole_size > 512, fragment hole will be truncated to 512 -
> fragment_chunk_size due to we won't create hole with enough size as
> seg->next_blkoff has crossed end of current segment.
>
Sorry, I don't get it. You mean making fragment_remained_hole as a
global variable?
Maybe, we run into the same race condition issue you told before for
fragment_remained_chunk.
Could you clarify this more?
Thanks,
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v4] f2fs: introduce fragment allocation mode mount option
On 2021/9/3 1:24, Daeho Jeong wrote:
@@ -2630,6 +2631,8 @@ static unsigned int __get_next_segno(struct f2fs_sb_info
*sbi, int type)
unsigned short seg_type = curseg->seg_type;
sanity_check_seg_type(sbi, seg_type);
+ if (f2fs_need_rand_seg(sbi))
+ return prandom_u32() % (MAIN_SECS(sbi) * sbi->segs_per_sec);
if (f2fs_need_seq_seg(sbi))
return 0;
static inline bool f2fs_need_seq_seg(struct f2fs_sb_info *sbi)
{
return F2FS_OPTION(sbi).fs_mode == FS_MODE_FRAGMENT_FIXED_BLK;
}
@@ -2707,12 +2715,29 @@ static int __next_free_blkoff(struct f2fs_sb_info *sbi,
static void __refresh_next_blkoff(struct f2fs_sb_info *sbi,
struct curseg_info *seg)
{
- if (seg->alloc_type == SSR)
+ if (seg->alloc_type == SSR) {
seg->next_blkoff =
__next_free_blkoff(sbi, seg->segno,
seg->next_blkoff + 1);
- else
+ } else {
seg->next_blkoff++;
+ if (F2FS_OPTION(sbi).fs_mode == FS_MODE_FRAGMENT_FIXED_BLK) {
+ if (--seg->fragment_remained_chunk <= 0) {
+ seg->fragment_remained_chunk =
+ sbi->fragment_chunk_size;
+ seg->next_blkoff +=
+ sbi->fragment_hole_size;
One more concern... we'd better to save fragment_remained_hole as well
as fragment_remained_chunk, otherwise, if fragment_chunk_size +
fragment_hole_size > 512, fragment hole will be truncated to 512 -
fragment_chunk_size due to we won't create hole with enough size as
seg->next_blkoff has crossed end of current segment.
Thanks,
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
