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. 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. > - 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. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/