RE: [PATCH 11/16] f2fs: add inode operations for special inodes
From: Jaegeuk Kim
Date: Tue Oct 16 2012 - 23:44:05 EST
> 2012-10-16 (í), 16:14 +0000, Arnd Bergmann:
> > On Tuesday 16 October 2012, Jaegeuk Kim wrote:
> > > Thank you for a lot of points to be addressed. :)
> > > Maybe it's time to summarize them.
> > > Please let me know what I misunderstood.
> > >
> > > [In v2]
> > > - Extension list
> > > : Mkfs supports configuring extensions by user, and that information
> > > will be stored in the superblock. In order to reduce the cleaning overhead,
> > > f2fs supports an additional interface, ioctl, likewise ext4.
> > That is what I suggested but actually Dave Chinner is the person that you
> > need to listen to rather than me in this regard. Using an extended attribute
> > in the root node would be more appropriate to configure this than an ioctl.
> > > - The number of active logs
> > > : No change will be done in on-disk layout (i.e., max 6 logs).
> > > Instead, f2fs supports changing the number with a mount option.
> > > Currently, I think 4, 5, and 6 would be enough.
> > Right, that would be the minimum that I would ask for. If it is relatively
> > easy to support more than six logs in the file format without actually
> > implementing them in the code, you might want to support up to 16, just
> > to be future-proof.
> Ok, got it.
> > For the lower bound, being able to support as little as 2 logs for
> > cheap hardware would be nice, but 4 logs is the important one.
> > 5 logs is probably not all that important, as long as you have the
> > choice between 4 and 6. If you implement three different ways, I
> > would prefer have the choice of 2/4/6 over 4/5/6 logs.
> Ok, I'll try, but in the case of 2 logs, it may need to change recovery
> > > - Section size
> > > : Mkfs supports multiples of segments for a section, not power-of-two.
> > Right.
> > > [Future optimization]
> > > - Data separation
> > > : file access pattern, and else?
> > : Investigate the option to make large files erase block indirect rather than
> > part of the normal logs
> > There is one more more point that I have not mentioned before, which is the
> > alignment of write requests. As far as I can tell, you try to group writes
> > as much as possible, but the alignment and the minimum size is still just
> > 4 KB.
> > I fear that this might not be good enough for a lot of cases when
> > the page sizes grow and there is no sufficient amount of nonvolatile
> > write cache in the device. I wonder whether there is something that can
> > be done to ensure we always write with a minimum alignment, and pad
> > out the data with zeroes if necessary in order to avoid getting into
> > garbage collection on devices that can't handle sub-page writes.
> You're very familiar with flash. :)
> Yes, as the page size grows, the sub-page write issue is one of the
> most critical problems.
> I also thought this before, but I have not made a conclusion until now.
> Because, I don't know how to deal with this in other companies, but,
> I've seen that so many firmware developers in samsung have tried to
> reduce this overhead by adapting many schemes.
> I guess very cautiously that other companies also handle this well.
> Therefore, I keep a question whether file system should care about
> this perfectly or not.
> > Arnd
As discussed with Dave, I propose the following items.
- Extension list
: Mkfs supports configuring extensions by user, and that information
will be stored in the superblock.
I'll add a mount option to enable/disable using the extension list.
Instead, f2fs supports xattr to give a hint to any files.
After supporting this by VFS, it'll be removed.
- The number of active logs
: For compatibility, on-disk layout supports max 16 logs.
Instead, f2fs supports configuring the number of active logs that
will be used by a mount option.
The option supports 2, 4, and 6 logs.
- Section size
: Mkfs supports multiples of segments for a section, not power-of-two.
- Data separation
: file access pattern
: Investigate the option to make large files erase block indirect rather than
part of the normal logs
: sub-page write avoidance
> Jaegeuk Kim
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/