All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Brown <david.brown@hesbynett.no>
To: linux-raid@vger.kernel.org
Subject: Re: additional feature for linear
Date: Sat, 17 Sep 2011 17:03:41 +0200	[thread overview]
Message-ID: <j52csd$3c2$1@dough.gmane.org> (raw)
In-Reply-To: <CAC_HdUr9DHt9uQGj=zJcgGvTknckfhyykDBX11XgX+wgOhHQUg@mail.gmail.com>

On 17/09/11 09:12, Henti Smith wrote:
> Good day,
>
> I have an itch I'm hoping somebody can provide me information with to
> scratch it. Please be patient, I'm not very well versed in  all the
> technical information regarding RAID, so I'm still finding my way
> around.
>
> Lets start with the itch.
>
> I'm looking for a way to take 3 drives and create one pool. This is
> similar to linear mode, but in this case if a drive in the linear mode
> fail the rest of the pool is intact and just the missing files are
> removed from the "device"
>
>  From my reading it looks like linear mode is the most likely
> candidate, but there is no guarantee that the remaining data will be
> accessible.
>
> "If one disk crashes you will most probably lose all your data. You
> can however be lucky to recover some data, since the filesystem will
> just be missing one large consecutive chunk of data"
>
> Would it not be possible to add functions to linear mode to mark this
> missing chunks as "bad blacks" and let the FS deal with it as such
> thereby allowing you to mount the linear device as per normal and
> still access the remaining data ?
>
> Id this is not possible, is there not some other way to implement this ?
>
> I see there is some mails regarding adding additional drives to linear
> as well and that the correct way is to stop the linear array and
> recreate it with additional drives. Is this correct ?
>
> I also see there was work being done on extending the array while
> online. Was this ever done ?
>
> Regards
> Henti

All this would require a filesystem that can cope with suddenly losing 
large numbers of disk blocks.  Most file systems can't - so even if the 
raid layer simply marked the missing chunks as bad, the filesystem would 
die.

What you are asking for here is a filesystem that understands the 
separate disks, and is careful to put individual files and related 
metadata and directories onto individual disks (so that when a disk 
dies, the file is either intact or completely lost), as well as 
duplicating its critical metadata so that it will survive a disk loss. 
All of this is the direct antithesis of raid, which aims to make 
multiple disks look like a single block device.

I believe at the moment, your only answer (other than to re-think your 
requirements) is ZFS.  It may be that btrfs has the features you need - 
they are certainly planned, as far as I know - but you'd have to be sure 
of using a recent kernel and utilities.



  reply	other threads:[~2011-09-17 15:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-17  7:12 additional feature for linear Henti Smith
2011-09-17 15:03 ` David Brown [this message]
2011-09-17 15:20 ` Jérôme Poulin
2011-09-17 15:32   ` Henti Smith
2011-09-17 15:47     ` David Brown
2011-09-20  0:28       ` RAID1 with MBR and GPT fails to auto-assemble during boot Jim Schatzman

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='j52csd$3c2$1@dough.gmane.org' \
    --to=david.brown@hesbynett.no \
    --cc=linux-raid@vger.kernel.org \
    /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.