All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: "Ted Ts'o" <tytso@mit.edu>
Cc: Alex Elder <elder@dreamhost.com>, <linux-fsdevel@vger.kernel.org>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH, RFC 0/3] Introduce new O_HOT and O_COLD flags
Date: Fri, 20 Apr 2012 12:31:52 +0300	[thread overview]
Message-ID: <4F912D08.9020907@panasas.com> (raw)
In-Reply-To: <20120420024511.GB24486@thunk.org>

On 04/20/2012 05:45 AM, Ted Ts'o wrote:

> The other approach is to leave things roughly undefined, and accept
> the fact that applications which use this will probably be specialized
> applications that are very much aware of what file system they are
> using, 


If that is the case then I prefer an FS specific IOCTL. Since the app
already has FS specific code built in.

> and just need to pass minimal hints to the application in a
> general way, and that's the approach I went with in this O_HOT/O_COLD proposal.
> 


You are contradicting yourself. Above you say specific FS (read ext4)
and here you say "general way".

Please show me how your proposal is not ext4 outer-rim specific, in devices
that are single rotational disks.

What does the "general way" mean?

> I suspect that HOT/COLD is enough to go quite far even for tiered
> storage; maybe at some point we will want some other, more
> fine-grained interface where an application program can very precisely
> dial in their requirements in a T10-like fashion.  Perhaps.  But I
> don't think having a simple O_HOT/O_COLD interface precludes the
> other, or vice versa.  In fact, one advantage with sticking with
> HOT/COLD is that there's much less chance of bike-shedding, with
> people arguing over what a more fine-grained interface might look like.
> 


But bike-shedding is exactly what you propose. (well not that you actually
stated what you propose)

Your patch says "beginning of the disk" but the flag is called O_HOT,
That's bike-shedding. You hope there will be new meaning for it in the
future.

> So why not start with this, and if we need to use something more
> complex later, we can cross that bridge if and when we get to it?  In
> the meantime, I think there are valid uses of this simple, minimal
> interface in the case of a local disk file system supporting a cluster
> file system such as Hadoopfs or TFS.  One of the useful things that
> came out of the ext4 workshop where we got to talk to developers from
> Taobao was finding out how much their interests matched with some of
> the things we've talked about doing at Google to support our internal
> customers.
> 


This all reads, ext4 specific / app specific. Why a general API? and
why must it be at create?

> 	       	      	    	 	   - Ted


Thanks
Boaz


  reply	other threads:[~2012-04-20  9:31 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-19 19:20 [PATCH, RFC 0/3] Introduce new O_HOT and O_COLD flags Theodore Ts'o
2012-04-19 19:20 ` [PATCH, RFC 1/3] fs: add new open flags O_HOT and O_COLD Theodore Ts'o
2012-04-19 19:20 ` [PATCH, RFC 2/3] fs: propagate the open_flags structure down to the low-level fs's create() Theodore Ts'o
2012-04-19 19:20 ` [PATCH, RFC 3/3] ext4: use the O_HOT and O_COLD open flags to influence inode allocation Theodore Ts'o
2012-04-19 19:45   ` Eric Sandeen
2012-04-19 19:59     ` Ted Ts'o
2012-04-19 22:55       ` Andreas Dilger
2012-04-19 23:27   ` Dave Chinner
2012-04-20  2:26     ` Ted Ts'o
2012-04-21  0:57       ` Dave Chinner
2012-04-20  0:26 ` [PATCH, RFC 0/3] Introduce new O_HOT and O_COLD flags Alex Elder
2012-04-20  2:45   ` Ted Ts'o
2012-04-20  9:31     ` Boaz Harrosh [this message]
2012-04-20  9:12 ` Boaz Harrosh
2012-04-20  9:45   ` Lukas Czerner
2012-04-20 11:01     ` James Bottomley
2012-04-20 11:23       ` Lukas Czerner
2012-04-20 14:07         ` Christoph Lameter
2012-04-20 14:42         ` James Bottomley
2012-04-20 14:58           ` Ted Ts'o
2012-04-21 23:56             ` KOSAKI Motohiro
2012-04-21 23:56               ` KOSAKI Motohiro
2012-04-22  6:30               ` Nick Piggin
2012-04-23  8:23                 ` James Bottomley
2012-04-23  8:23                   ` James Bottomley
2012-04-23 11:47                   ` Nick Piggin
2012-04-24  6:18                     ` Nick Piggin
2012-04-24 15:00                       ` KOSAKI Motohiro
2012-04-21 18:26       ` Jeff Garzik
2012-04-21 18:26         ` Jeff Garzik
2012-04-20 10:16 ` Bernd Schubert
2012-04-20 10:38   ` Lukas Czerner
2012-04-21 18:24 ` Jeff Garzik
2012-04-24 16:07 ` Alex Elder
2012-04-24 19:33 ` Jamie Lokier

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=4F912D08.9020907@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=elder@dreamhost.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.