All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Ram Pai <linuxram@us.ibm.com>
Cc: Vyacheslav Dubeyko <slava@dubeyko.com>, linux-fsdevel@vger.kernel.org
Subject: Re: [RFC PATCH 1/1] vfs: Filemash fs
Date: Thu, 11 Apr 2013 10:44:32 +1000	[thread overview]
Message-ID: <20130411004431.GD10481@dastard> (raw)
In-Reply-To: <20130408034709.GA31490@ram.oc3035372033.ibm.com>

On Mon, Apr 08, 2013 at 11:47:09AM +0800, Ram Pai wrote:
> 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?

Overlay-style filesystem that keeps the mashup information in
xattrs in the underlying files.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2013-04-11  0:44 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
2013-04-11  0:44     ` Dave Chinner [this message]
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=20130411004431.GD10481@dastard \
    --to=david@fromorbit.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linuxram@us.ibm.com \
    --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 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.