All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Sayan Ghosh <sgdgp.2014@gmail.com>
Cc: Andreas Dilger <adilger@dilger.ca>,
	"Theodore Y. Ts'o" <tytso@mit.edu>,
	Ext4 Developers List <linux-ext4@vger.kernel.org>,
	Linux FS Devel <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: Wed, 11 Apr 2018 09:39:48 +1000	[thread overview]
Message-ID: <20180410233948.GE729@dastard> (raw)
In-Reply-To: <CAExFE6nqRk6zv-2NX40eCFe3CPhQKuPF86e_PuCBAgNwJBkpSg@mail.gmail.com>

On Tue, Apr 10, 2018 at 03:26:11PM +0530, Sayan Ghosh wrote:
> > That said, having a hard-coded separation of flash vs. disks does not
> > make sense, even from an intermediate development point of view.  There
> > definitely should be a block-device interface for querying what the
> > actual layout is, perhaps something like the SMR zones?
> 
> Yes, I agree, that the ideal situation would be to have a mechanism to
> identify the segment boundaries automatically inside the LVM. But we
> were not able to get a method to access the boundaries or rather the
> location of a free block in each segment by such system call.
> So, in order to just test out the system we proceeded by hardcoding
> the boundaries as per our simulated LVM. But since this is not
> practical we provided the TODO/FIX IT in those areas. We are still
> looking for a good mechanism, and would welcome any
> advice/suggestions.
> 
> Also, we chose to use Ext4 since it is generally the most commonly
> used file system in linux based systems. However, I am not aware if
> the problem of getting the boundaries can be solved in a simpler
> manner by using XFS.

SSD for the data device, HDD for the realtime device, device
auto-selection based on initial allocation size patchset like this
one:

https://marc.info/?l=linux-xfs&m=151190613327238&w=2

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2018-04-10 23:39 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
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 [this message]
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=20180410233948.GE729@dastard \
    --to=david@fromorbit.com \
    --cc=adilger@dilger.ca \
    --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 \
    --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.