linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Sayan Ghosh <sgdgp.2014@gmail.com>
Cc: linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	"Bhattacharya, Suparna" <suparna.bhattacharya@hpe.com>,
	niloy ganguly <ganguly.niloy@gmail.com>,
	Madhumita Mallick <madhu.cse.ju@gmail.com>,
	"Bharde, Madhumita" <madhumita.bharde@hpe.com>
Subject: Re: [Patch 0/4] RFC : Support for data gradation of a single file.
Date: Fri, 6 Apr 2018 18:27:22 -0400	[thread overview]
Message-ID: <20180406222722.GA30438@thunk.org> (raw)
In-Reply-To: <CAExFE6n2npo8Uomk=bNYnC4CVL9aWQDMRdOeav0vAdce1prNMQ@mail.gmail.com>

Hi Sayan,

It wasn't clear what was your purpose in posting these patches.  There
are a large number of ways in which they simply aren't ready for
upstream merging.  As a short list:

1)  They are against an ancient version of the kernel (4.7.2).

2)  There are a large number of TODO's in it in the code

3) The boundary between the two different tiers of storage is
currently harded in a header file using a #define (!).


If the goal is to gather comments about the design, I wish you had
presented the problem statement to the ext4 mailig list much earlier.
It might have saved you time in terms since we could have given you
feedback before you had done all of this work on this patch set.

Andreas' comments about making the allocation hints persistent not
making any sense are very much on target.  Once the file is written,
the hints won't be needed at all.

In addition, you should strongly think about some way propagating the
fact that some blocks in device-mapper device are backed by DAX, and
others are not, as a device-mapper interface.  And it might not
necessarily a single break point where below a block number is SSD or
HDD storage, and above a block number it's DAX storage.

The other thing to consider is whether it makes any sense at all to
solve this problem by haing a single file system where part of the
storage is DAX, and part is not.  Why not just have two file systems,
one which is 100% DAX, and another which is 100% HDD/SSD, and store
the data in two files in two different file sytsems?

						- Ted

  parent reply	other threads:[~2018-04-06 22:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-06 11:41 [Patch 0/4] RFC : Support for data gradation of a single file Sayan Ghosh
2018-04-06 21:31 ` Andreas Dilger
2018-04-06 22:27 ` Theodore Y. Ts'o [this message]
2018-04-09  4:03   ` Andreas Dilger
2018-04-10  9:46     ` Sayan Ghosh
2018-04-10 18:40       ` Andreas Dilger
2018-04-11  9:20         ` Bhattacharya, Suparna
2018-04-10  9:56     ` Sayan Ghosh
2018-04-10 23:39       ` Dave Chinner
2018-04-10  9:52   ` Sayan Ghosh

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=20180406222722.GA30438@thunk.org \
    --to=tytso@mit.edu \
    --cc=ganguly.niloy@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=madhu.cse.ju@gmail.com \
    --cc=madhumita.bharde@hpe.com \
    --cc=sgdgp.2014@gmail.com \
    --cc=suparna.bhattacharya@hpe.com \
    /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;
as well as URLs for NNTP newsgroup(s).