From: Gregory Seidman <gsslist+linuxraid@anthropohedron.net>
To: linux-raid@vger.kernel.org
Subject: Re: Best way to achieve large, expandable, cheap storage?
Date: Fri, 30 Sep 2005 14:16:43 -0400 [thread overview]
Message-ID: <20050930181643.GA23130@anthropohedron.net> (raw)
In-Reply-To: <dhje16$tmq$1@sea.gmane.org>
On Fri, Sep 30, 2005 at 02:20:11PM +0100, Robin Bowes wrote:
} I have a business opportunity which would involve a large amount of
} storage, possibly growing to 10TB in the first year, possibly more. This
} would be to store media files - probably mainly .flac or .mp3 files.
}
} Concurrency wouldn't be particularly important as I'd be the only person
} access the storage and I have no need for lightning speed.
If you aren't overly concerned about speed, you can use LVM. If you want
redundancy as well as disk-spanning, you can use RAID as well. That is what
I am planning on doing for myself. There are shortcomings, however. See
below.
} It would be nice to be able to start smallish and grow as required, but
} my experience of linux raid to date is that it's not possible to resize
} arrays. (I have a 1TB array built from 6 x 250GB SATA discs on Promise
} SATA150 TX4 controllers).
}
} Can anyone offer recommendations as to the most cost-effective way to
} achieve this sort of storage?
}
} Are there any limitations I might run into using md on Linux?
}
} For example, suppose I get something like this [1] and throw in an
} appropriate mobo/processor etc and 24 x 500 GB SATA discs; would md/mdadm
} be able to create a single 11TB RAID5 partition, ie (23-1) x 500, with a
} hot-spare? Would this be a sensible thing to do?
}
} What about file-system limitations, e.g. would ext3/reiser/XFS support an
} 11TB partition?
AFAIK, all three of those filesystems can handle at least 16 exabytes of
data. I may be wrong, however.
} Would I be better off creating smaller volumes combining them with RAID0?
}
} I'd appreciate any tips/suggestions/advice/pointers to further sources of
} information.
LVM allows you to add more PVs (physical volumes, a.k.a. disks or
partitions) to a VG (volume group). You can then extend an LV (logical
volume) and the filesystem on it. Basically it is like a growable RAID0. It
is even possible to retire old PVs as long as there is sufficient room on
other PVs to take up the slack. This means that in five years when you can
get a 3TB disk for $300 you'll be able to add them in and replace your old,
outdated 250GB drives.
One advantage of LVM is snapshotting. It allows you to basically keep a
cheap diff backup of your disk. It's a really cool feature, but I'm not
going to go into detail about it here.
The main disadvantage is that while you can have a hot spare as part of a
RAID10 to be automatically used in any RAID1 pair as needed, LVM does not
integrate closely enough with md to allow that. You can have a warm spare
all ready to go, but you would have to actually assign it to the
appropriate md device for it to be used. Your best bet is to do a RAID10 with
however many hot spares on your set of disks and put LVM on top of that.
When you want to expand, add another PV to the LVM. Don't rely on LVM to
make a single device from a group of disks bought at any one time, just to
add new storage.
} Thanks,
} R.
--Greg
next prev parent reply other threads:[~2005-09-30 18:16 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-30 13:20 Best way to achieve large, expandable, cheap storage? Robin Bowes
2005-09-30 13:29 ` Robin Bowes
2005-09-30 18:28 ` Brad Dameron
2005-09-30 19:20 ` Dan Stromberg
2005-09-30 18:16 ` Gregory Seidman [this message]
2005-09-30 18:34 ` Andy Smith
2005-10-02 4:36 ` Christopher Smith
2005-10-02 7:09 ` Tyler
2005-10-03 3:19 ` Christopher Smith
2005-10-03 16:33 ` Sebastian Kuzminsky
2005-10-04 4:09 ` Christopher Smith
2005-10-20 10:23 ` Robin Bowes
2005-10-20 11:19 ` Gregory Seidman
2005-10-20 11:41 ` Robin Bowes
2005-10-21 4:42 ` Christopher Smith
2005-10-21 16:48 ` Gil
2005-10-21 20:08 ` Robin Bowes
2005-10-21 4:40 ` Christopher Smith
-- strict thread matches above, loose matches on Subject: below --
2005-10-27 19:12 Andrew Burgess
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=20050930181643.GA23130@anthropohedron.net \
--to=gsslist+linuxraid@anthropohedron.net \
--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).