linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kent Overstreet <kent.overstreet@gmail.com>
To: linux-raid@vger.kernel.org
Cc: Neil Brown <neilb@suse.de>
Subject: An extensible superblock
Date: Tue, 11 Jan 2011 10:21:43 -0800	[thread overview]
Message-ID: <4D2C9FB7.6050806@gmail.com> (raw)

This is, in a roundabout way, an extension of some stuff I was talking 
to Neil about - but this is slightly more wild speculation.

Background: bcache
http://bcache.evilpiepirate.org

Bcache currently caches block devices transparently; this is useful but 
unsafe. It needs a superblock for the backing device, and it turns out 
what it needs out of a superblock is not very dissimilar from what md 
does, so I've been thinking about how to best go about using md.

Well, the annoying thing about that for the end user is that if you want 
to cache your hard drive safely, you have to plan ahead... there's no 
technical reason you shouldn't be able to add a cache to the filesystem 
you've already got but you need a place to put the superblock.

The exact same problem exists with raid: you installed to a single disk, 
you decide you want to mirror it - there's no good way of doing that. 
There's three different solutions I know of (make a degraded raid1 on 
the new disk, copy everything over; use a 1.2 superblock - if it fits; 
or when you first install force create a single disk raid1). They work 
but they're hacks, it'd be nice to have something better.

The last solution - start with a raid superblock - would be particularly 
nice if there was an explicit "noop" raid level; you could quite 
conceivable grow from a single disk to a raid6, online. Trouble is, you 
could add a cache, create a raid, but not both.

Well, not without a new superblock, which is why I prefaced this by 
calling it wild speculation - I really like this solution but it'd be a 
fair amount of work.

Change the superblock so it describes a tree structure:
Leaf nodes correspond to component devices. Thus, a superblock that 
describes an array with only one component would be a noop superblock.

Then, interior nodes correspond to raid arrays or cache sets. Much of 
what's in the start of the version 1 superblock would be here.

Anyways, once you've got that you can have a standard superblock that 
you use for everything, and you can safely and easily transition to 
whatever you might want to in the future.


             reply	other threads:[~2011-01-11 18:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-11 18:21 Kent Overstreet [this message]
2011-01-11 19:52 ` An extensible superblock Jonathan Brassow
2011-01-11 20:02   ` Kent Overstreet

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=4D2C9FB7.6050806@gmail.com \
    --to=kent.overstreet@gmail.com \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    /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).