RE: [PATCH 11/16] f2fs: add inode operations for special inodes

[Jaegeuk Kim]

> On Monday 15 October 2012, Changman Lee wrote:
> > 2012ë 10ì 15ì ìììì Arnd Bergmann<arnd@xxxxxxxx>ëì ìì:
> > > It is only a performance hint though, so it is not a correctness issue the
> > > file system gets it wrong. In order to do efficient garbage collection, a log
> > > structured file system should take all the information it can get about the
> > > expected life of data it writes. I agree that the list, even in the form of
> > > mkfs time settings, is not a clean abstraction, but in the place of an Android
> > > phone manufacturer I would still enable it if it promises a significant
> > > performance advantage over not using it. I guess it would be nice if this
> > > could be overridden in some form, e.g. using an ioctl on the file as ext4 does.
> > >
> > Right. This is related with HOT/COLD separation policy of f2fs. If we know
> > that data is COLD, we can manage gc effectively.
> > I think that ext lists are placed in sb is better like your advice because
> > it's difficult to fix user app. Although it's nasty way.
> 
> Ok. I think you should adapt the terminology though. Right now, the optimization
> is to mark the data as COLD because we expect it to be written less often than
> other kinds of data. However, the hot/cold terms are usually only applied to
> data that we assume is going to be written soon or not based on how often
> the same data has been accessed in the past.
> 
> Anything you detect from the file name is not really a hint on hot/cold
> files, but rather on the expected access pattern: These files are going
> to be written once, and will be read-only after that, they are probably
> multiple megabytes in size, and if you have a lot of them, they are likely
> to live for the same time.
> 
> It may well be possible that we later decide to use the hint in a different
> way, e.g. to put these files into yet another separate log, aside from
> other hot or cold files.
> 
> > > We should also take the kinds of access we have seen on a file into account.
> > > E.g. if someone opens a file O_RDWR and performs seek or pwrite on it, we can
> > > assume that it's not in the category of typical media files, and a file that
> > > gets written to disk linearly in multiple megabytes might belong into the
> > > category even if it is named otherwise.
> > >
> > This is more general but it's hard to adapt now.
> 
> I think it's important to leave the option open for a future optimization.
> Right now, what we have to get agreement on is the on-disk format, because
> we absolutely don't want to make incompatible changes to that once f2fs
> has been merged into the kernel and is getting used on real systems.
> 
> This is independent of how the code is implemented at the moment, and
> any tuning regarding how to group different kinds of data into the six
> logs is completely up to how things work out in practice. But you should
> definitely ensure that those changes don't require changing the format
> if we decide to use a different number of logs in the future, or to
> use the logs differently.
> 
> The split between logs for nodes on the one hand and data on the other
> is something that can well be hardcoded, and it's ok to have a hard
> upper bound on the number of logs in the file system, possibly higher
> than 6.
> 

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.

- 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.

- Section size
  : Mkfs supports multiples of segments for a section, not power-of-two.

[Future optimization]
- Data separation
  : file access pattern, and else?

> 	Arnd

--
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/