Message-id: <015901cdab42$06deac20$149c0460$%kim@samsung.com>
Date:	Tue, 16 Oct 2012 11:00:32 +0900
From:	Jaegeuk Kim <jaegeuk.kim@...sung.com>
To:	'Dave Chinner' <david@...morbit.com>,
	'Arnd Bergmann' <arnd@...db.de>
Cc:	'Vyacheslav Dubeyko' <slava@...eyko.com>,
	'Jaegeuk Kim' <jaegeuk.kim@...il.com>, viro@...iv.linux.org.uk,
	'Theodore Ts'o' <tytso@....edu>, gregkh@...uxfoundation.org,
	linux-kernel@...r.kernel.org, chur.lee@...sung.com,
	cm224.lee@...sung.com, jooyoung.hwang@...sung.com
Subject: RE: [PATCH 11/16] f2fs: add inode operations for special inodes

> On Sun, Oct 14, 2012 at 03:19:37PM +0000, Arnd Bergmann wrote:
> > On Sunday 14 October 2012, Vyacheslav Dubeyko wrote:
> > > On Oct 14, 2012, at 11:09 AM, Jaegeuk Kim wrote:
> > > > 2012-10-14 (일), 02:21 +0400, Vyacheslav Dubeyko:
> > > Extended attributes are more flexible way, from my point of view. The xattr gives
> > > possibility to make hint to filesystem at any time and without any dependencies with
> > > application's functional opportunities. Documented way of using such extended attributes
> > > gives to user flexible way of manipulation of filesystem behavior (but I remember that
> > > you don't believe in an user :-)).
> > >
> > > So, I think that fadvise() and extended attributes can be complementary solutions.
> >
> > Right. Another option is to have ext4 style attributes, see
> > http://linux.die.net/man/1/chattr
> 
> Xattrs are much prefered to more "ext4 style" flags because xattrs
> are filesystem independent. Indeed, some filesystems can't store any
> new "ext4 style" flags without a change of disk format or
> internally mapping them to an xattr. So really, xattrs are the best
> way forward for such hints.
> 
> > Unlike extended attributes, there is a limited number of those,
> > and they can only be boolean flags, but that might be enough for
> > this particular use case.
> 
> A boolean is not sufficient for access policy hints. An extensible
> xattr format is probably the best approach to take here, so that we
> can easily introduce new access policy hints as functionality is
> required. Indeed, an extensible xattr could start with just a
> hot/cold boolean, and grow from there....
> 
> > The main reason I can see against extended attributes is that they are not stored
> > very efficiently in f2fs, unless a lot of work is put into coming up with a good
> > implementation. A single flags bit can trivially be added to the inode in
> > comparison (if it's not there already).
> 
> That's a deficiency that should be corrected, then, because xattrs
> are very common these days.

IMO, most file systems including f2fs have some inefficiency to store
and retrieve xattrs, since they have to allocate an additional block.
The only distinct problem in f2fs is that there is a cleaning overhead.
So, that's the why xattr is not an efficient way in f2fs.

OTOH, I think xattr itself is for users, not for communicating
between file system and users.
Moreover, I'm not sure in the current android, but I saw ICS android
did not call any xattr operations, even if mount option was enabled.

> 
> And given that stuff like access frequency tracking is being
> implemented at the VFS level, access policy hints should also be VFS
> functionality. A bad filesystem implementation should not dictate
> the interface for generically useful functionality....
> 
> > > Anyway, hardcoding or saving in filesystem list of file extensions is a nasty way. It
> > > can be not safe or hardly understandable by users the way of reconfiguration filesystem
> > > by means of tunefs or debugfs with the purpose of file extensions addition in such
> > > "black-box" as TV or smartphones, from my point of view.
> >
> > 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.
> 
> An xattr on the root inode that holds a list like this is something
> that could be set at mkfs time, but then also updated easily by new
> software packages that are installed...
> 
> > We should also take the kinds of access we have seen on a file into account.
> 
> Yes, but it should be done at the VFS level, not in the filesystem
> itself. Integrated into the current hot inode/range tracking that is
> being worked on right now, I'd suggest.
> 
> IOWs, these access policy issues are not unique to F2FS or it's use
> case. Anything to do with access hints, policy, tracking, file
> classification, etc that can influence data locality, reclaim,
> migration, etc need to be dealt with at the VFS, independently of a
> specific filesystem. Filesystems can make use of that information
> how they please (whether in the kernel or via userspace tools), but
> having filesystem specific interfaces and implementations of the
> same functionality is extremely wasteful. Let's do it once, and do
> it right the first time. ;)

I agree that VFS should support something, but before then, it needs
to do something by the file system first.
Because, we have to figure out what kind of information are really useful.
Thanks,

> 
> Cheers,
> 
> Dave.
> --
> Dave Chinner
> david@...morbit.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists