mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jaegeuk Kim <jaegeuk.kim@samsung.com>
To: "'Arnd Bergmann'" <arnd@arndb.de>
Cc: "'Changman Lee'" <cm224.lee@gmail.com>,
	"'Vyacheslav Dubeyko'" <slava@dubeyko.com>,
	viro@zeniv.linux.org.uk, "'Theodore Ts'o'" <tytso@mit.edu>,
	gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org,
	chur.lee@samsung.com, cm224.lee@samsung.com,
	jooyoung.hwang@samsung.com
Subject: RE: [PATCH 11/16] f2fs: add inode operations for special inodes
Date: Wed, 17 Oct 2012 12:44:12 +0900	[thread overview]
Message-ID: <021601cdac19$ac462350$04d269f0$%kim@samsung.com> (raw)
In-Reply-To: <1350423780.1958.86.camel@kjgkr>

> 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
> routines.
> 
> >
> > > - 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.
> 
> Yes.
> 
> > 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.
> 
> Thanks,
> 
> >
> > 	Arnd
> 

As discussed with Dave, I propose the following items.

[In v2]
- 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.

[Future optimization]
- 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

Thanks,

> --
> Jaegeuk Kim
> Samsung


  reply	other threads:[~2012-10-17  3:44 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-05 12:03 김재극
2012-10-06 18:59 ` Al Viro
2012-10-13 20:52 ` Arnd Bergmann
2012-10-13 21:57   ` Vyacheslav Dubeyko
2012-10-13 22:21   ` Vyacheslav Dubeyko
2012-10-14  7:09     ` Jaegeuk Kim
2012-10-14 12:06       ` Vyacheslav Dubeyko
2012-10-14 15:19         ` Arnd Bergmann
     [not found]           ` <CAN863PuYDSSFmaKtsVvdX4aFpS8hAMvFmhJpsky0x=ySn0QsqQ@mail.gmail.com>
2012-10-15 14:05             ` Arnd Bergmann
2012-10-16  2:29               ` Jaegeuk Kim
2012-10-16 16:14                 ` Arnd Bergmann
2012-10-16 21:43                   ` Jaegeuk Kim
2012-10-17  3:44                     ` Jaegeuk Kim [this message]
2012-10-17 12:22                       ` Arnd Bergmann
2012-10-17  8:35                     ` Arnd Bergmann
2012-10-15 22:34           ` Dave Chinner
2012-10-16  2:00             ` Jaegeuk Kim
2012-10-16 11:38               ` Arnd Bergmann
2012-10-16 20:38                 ` Jaegeuk Kim
2012-10-17 12:25                   ` Arnd Bergmann
2012-10-18  5:37                     ` Jaegeuk Kim
2012-10-16 20:44                 ` Dave Chinner
2012-10-16 22:30                   ` Jaegeuk Kim
2012-10-16 22:54                     ` Dave Chinner
2012-10-17  3:25                       ` Jaegeuk Kim
2012-10-17 12:50                     ` Arnd Bergmann
2012-10-24  2:49                       ` Dave Chinner
2012-10-24 12:02                         ` Arnd Bergmann
2012-10-14  6:51   ` Jaegeuk Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='021601cdac19$ac462350$04d269f0$%kim@samsung.com' \
    --to=jaegeuk.kim@samsung.com \
    --cc=arnd@arndb.de \
    --cc=chur.lee@samsung.com \
    --cc=cm224.lee@gmail.com \
    --cc=cm224.lee@samsung.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jooyoung.hwang@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=slava@dubeyko.com \
    --cc=tytso@mit.edu \
    --cc=viro@zeniv.linux.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome