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.
next prev parent 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 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).