linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ram Pai <linuxram@us.ibm.com>
To: Vyacheslav Dubeyko <slava@dubeyko.com>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [RFC PATCH 1/1] vfs: Filemash fs
Date: Mon, 8 Apr 2013 11:47:09 +0800	[thread overview]
Message-ID: <20130408034709.GA31490@ram.oc3035372033.ibm.com> (raw)
In-Reply-To: <0B472AFB-371E-45E8-BF9F-AB740BCDDBE5@dubeyko.com>

On Sun, Apr 07, 2013 at 03:03:29PM +0400, Vyacheslav Dubeyko wrote:
> Hi Ram,
> 
> On Apr 3, 2013, at 2:23 PM, Ram Pai wrote:
> 
> > The following patch implements a filesystem driver which provides the ability
> > to mashup exisiting files in creative ways in-order to create new files.
> > 
> > Think of it as a way to union files; not filesystems.
> > 
> > Its a prototype idea with a prototype implementation.  Tested and working on
> > 3.0.9-rc1.  I have included Documentation file which details the idea with
> > examples and possible applications.
> > 
> > Any suggestions/ideas to make this useful and generally applicable is very much
> > appreciated!
> > 
> 
> Why do you think that your solution is better than LVM or RAID technologies?

Each has its own place. LVM/RAID lets you build block devices in
creative ways. Filemashup lets you build files in creative ways.
So both solutions have their own application which are not necessarily
the same. Hence I can't say one is better than the other.

> 
> I think that using mount options in your solution is weird way. Let's imagine a file that it will include a hundreds parts.

Well, I tried to mimic the same kind of approach used by overlayfs to
union-mount directories. 

Yes. you are right. if you want to mashup hundreds of files, then you
will have to provide all those hundred files on the command line, or you
can put the options in /etc/fstab.  Can you think of a better approach?


> 
> Moreover, I think that in your approach the using of remount option is very necessary. It needs for adding file's parts and change mounted parts.

Or use an ioctl or sysfs mechanism to dynamically change the layout of
the files.

Thanks for your comments, I certainly want to know if this idea is worth
pursuing further. I certainly see applications of this idea for my own
personal use, the best being, the ablilty to extend my files across
filesystems.

RP


  reply	other threads:[~2013-04-08  3:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-03 10:23 [RFC PATCH 1/1] vfs: Filemash fs Ram Pai
2013-04-07 11:03 ` Vyacheslav Dubeyko
2013-04-08  3:47   ` Ram Pai [this message]
2013-04-11  0:44     ` Dave Chinner
2013-04-24  8:03       ` Ram Pai
  -- strict thread matches above, loose matches on Subject: below --
2013-04-03  9:16 Ram Pai

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=20130408034709.GA31490@ram.oc3035372033.ibm.com \
    --to=linuxram@us.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=slava@dubeyko.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).