lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.00.1204201120060.27750@dhcp-27-109.brq.redhat.com>
Date:	Fri, 20 Apr 2012 11:45:19 +0200 (CEST)
From:	Lukas Czerner <lczerner@...hat.com>
To:	Boaz Harrosh <bharrosh@...asas.com>
cc:	"Theodore Ts'o" <tytso@....edu>, linux-fsdevel@...r.kernel.org,
	Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [PATCH, RFC 0/3] Introduce new O_HOT and O_COLD flags

On Fri, 20 Apr 2012, Boaz Harrosh wrote:

> On 04/19/2012 10:20 PM, Theodore Ts'o wrote:
> 
> > As I had brought up during one of the lightning talks at the Linux
> > Storage and Filesystem workshop, I am interested in introducing two new
> > open flags, O_HOT and O_COLD.  These flags are passed down to the
> > individual file system's inode operations' create function, and the file
> > system can use these flags as a hint regarding whether the file is
> > likely to be accessed frequently or not.
> > 
> > In the future I plan to do further work on how ext4 would use these
> > flags, but I want to first get the ability to pass these flags plumbed
> > into the VFS layer and the code points for O_HOT and O_COLD reserved.
> > 
> > 
> > Theodore Ts'o (3):
> >   fs: add new open flags O_HOT and O_COLD
> >   fs: propagate the open_flags structure down to the low-level fs's
> >     create()
> >   ext4: use the O_HOT and O_COLD open flags to influence inode
> >     allocation
> > 
> 
> 
> I would expect that the first, and most important patch to this
> set would be the man page which would define the new API. 
> What do you mean by cold/normal/hot? what is expected if supported?
> how can we know if supported? ....

Well, this is exactly my concern as well. There is no way anyone would
know what it actually means a what users can expect form using it. The
result of this is very simple, everyone will just use O_HOT for
everything (if they will use it at all).

Ted, as I've mentioned on LSF I think that the HOT/COLD name is really
bad choice for exactly this reason. It means nothing. If you want to use
this flag to place the inode on the faster part of the disk, then just
say so and name the flag accordingly, this way everyone can use it.
However for this to actually work we need some fs<->storage interface to
query storage layout, which actually should not be that hard to do. I am
afraid that in current form it will suit only Google and Taobao. I would
really like to have interface to pass tags between user->fs and
fs<->storage, but this one does not seem like a good start.

There was one flag you've mentioned on LSF which makes sense to me, but
unfortunately I can not see it here. It is O_TEMP, which says exactly
how user should use it, hence it will be useful.

Also we have to think about the interface for passing tags from users,
because clearly open flags does not scale. fnctl, or fadvise might be
better choice, but I understand that in some cases we need to have this
information on allocation and I am not sure if we can rely on delayed
allocation (it seems really hacky). Or maybe it can be fadvise/fnctl
flag for a directory, since files in one directory might have similar
access pattern and it also have the advantage of forcing users to divide
their files to the directories according to their use, which will be
beneficial anyway.

I have to admit that I do not have any particularly strong feeling about
any of those approaches (open/fnctl/fadvise/directory), but someone else
might... But I definitely think that we need to define the interface
well and also rather do it from bottom-up. There already is a need to have
fs<->storage information exchange interface for variety of reasons, so
why not start there first to see what can be provided ?

Thanks!
-Lukas

> 
> I presume you mean 3 levels (not even 2 bits) of what T10 called
> "read-frequency" or is that "write-frequency", or some other metrics
> you defined?
> 
> Well in the patchset you supplied it means closer to outer-edge.
> What ever that means? so in the case of ext4 on SSD or DM/MD or
> loop or thin provisioned LUN. How do I stop it. The code is already
> there in Kernel and the application is setting that flag at create,
> how do I make the FS not do that stupid, for me, thing?
> 
> I wish you'd be transparent, call it O_OUTER_DISK and be honest
> about it. The "undefined API" never ever worked in the past,
> why would it work now?
> 
> And Yes an fctrl is a much better match, and with delayed allocation
> that should not matter, right?
> 
> And one last thing. We would like to see numbers. Please show us where/how
> it matters. Are there down sides?. If it's so good we'd like to implement
> it too.


> 
> Thanks
> Boaz
> 
> >  fs/9p/vfs_inode.c           |    2 +-
> >  fs/affs/affs.h              |    2 +-
> >  fs/affs/namei.c             |    3 ++-
> >  fs/bfs/dir.c                |    2 +-
> >  fs/btrfs/inode.c            |    3 ++-
> >  fs/cachefiles/namei.c       |    3 ++-
> >  fs/ceph/dir.c               |    2 +-
> >  fs/cifs/dir.c               |    2 +-
> >  fs/coda/dir.c               |    3 ++-
> >  fs/ecryptfs/inode.c         |    5 +++--
> >  fs/exofs/namei.c            |    2 +-
> >  fs/ext2/namei.c             |    4 +++-
> >  fs/ext3/namei.c             |    5 +++--
> >  fs/ext4/ext4.h              |    8 +++++++-
> >  fs/ext4/ialloc.c            |   33 +++++++++++++++++++++++++++------
> >  fs/ext4/migrate.c           |    2 +-
> >  fs/ext4/namei.c             |   17 ++++++++++++-----
> >  fs/fat/namei_msdos.c        |    2 +-
> >  fs/fat/namei_vfat.c         |    2 +-
> >  fs/fcntl.c                  |    5 +++--
> >  fs/fuse/dir.c               |    2 +-
> >  fs/gfs2/inode.c             |    3 ++-
> >  fs/hfs/dir.c                |    2 +-
> >  fs/hfsplus/dir.c            |    5 +++--
> >  fs/hostfs/hostfs_kern.c     |    2 +-
> >  fs/hugetlbfs/inode.c        |    4 +++-
> >  fs/internal.h               |    6 ------
> >  fs/jffs2/dir.c              |    5 +++--
> >  fs/jfs/namei.c              |    2 +-
> >  fs/logfs/dir.c              |    2 +-
> >  fs/minix/namei.c            |    2 +-
> >  fs/namei.c                  |    9 +++++----
> >  fs/ncpfs/dir.c              |    5 +++--
> >  fs/nfs/dir.c                |    6 ++++--
> >  fs/nfsd/vfs.c               |    4 ++--
> >  fs/nilfs2/namei.c           |    2 +-
> >  fs/ocfs2/namei.c            |    3 ++-
> >  fs/omfs/dir.c               |    2 +-
> >  fs/ramfs/inode.c            |    3 ++-
> >  fs/reiserfs/namei.c         |    5 +++--
> >  fs/sysv/namei.c             |    4 +++-
> >  fs/ubifs/dir.c              |    2 +-
> >  fs/udf/namei.c              |    2 +-
> >  fs/ufs/namei.c              |    2 +-
> >  fs/xfs/xfs_iops.c           |    3 ++-
> >  include/asm-generic/fcntl.h |    7 +++++++
> >  include/linux/fs.h          |   14 ++++++++++++--
> >  ipc/mqueue.c                |    2 +-
> >  48 files changed, 143 insertions(+), 74 deletions(-)
> > 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ