All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin <m_btrfs@ml1.co.uk>
To: linux-btrfs@vger.kernel.org
Subject: RAID device nomination (Feature request)
Date: Thu, 18 Apr 2013 14:45:24 +0100	[thread overview]
Message-ID: <kkotdg$o1e$1@ger.gmane.org> (raw)

Dear Devs,

I have a number of esata disk packs holding 4 physical disks each where
I wish to use the disk packs aggregated for 16TB and up to 64TB backups...

Can btrfs...?

1:

Mirror data such that there is a copy of data on each *disk pack* ?

Note that esata shows just the disks as individual physical disks, 4 per
disk pack. Can physical disks be grouped together to force the RAID data
to be mirrored across all the nominated groups?


2:

Similarly for a mix of different storage technologies such as
manufacturer or type (SSD/HDD), can the disks be grouped to ensure a
copy of the data is replicated across all the groups?

For example, I deliberately buy HDDs from different
batches/manufacturers to try to avoid common mode or similarly timed
failures. Can btrfs be guided to safely spread the RAID data across the
*different* hardware types/batches?


3:

Also, for different speeds of disks, can btrfs tune itself to balance
the read/writes accordingly?


4:

Further thought: For SSDs, is the "minimise heads movement" 'staircase'
code bypassed so as to speed up allocation for the "don't care"
addressing (near zero seek time) of SSDs?



And then again: Is 64TBytes of btrfs a good idea in the first place?!

(There's more than one physical set of backups but I'd rather not suffer
weeks to recover from one hiccup in the filesystem... Should I partition
btrfs down to smaller gulps, or does the structure of btrfs in effect
already do that?)

Thanks,
Martin


             reply	other threads:[~2013-04-18 13:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-18 13:45 Martin [this message]
2013-04-18 14:06 ` RAID device nomination (Feature request) Hugo Mills
2013-04-18 16:29   ` Martin
2013-04-18 19:44     ` Hugo Mills
2013-04-19  0:31       ` Martin
2013-04-18 19:48   ` Alex Elsayed
2013-04-19  0:41     ` Martin
2013-04-19  3:05       ` Alex Elsayed

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='kkotdg$o1e$1@ger.gmane.org' \
    --to=m_btrfs@ml1.co.uk \
    --cc=linux-btrfs@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.