Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Here's the situation I was trying to work out in my head.
For a regular drive. The above scenario is not a problem. However, if I grow my raid (5) this makes things a little trickier, especially if I did not anticipate this.
For example, if I start with a 2TB raid 5 and partition it into 4 x 500 GB partitions all is well. What if I needed to grow this partition by another TB? It looks like I'm out of luck.
Am I correct, or is there something I'm not taking into consideration?
Depends on what your using. If your using the plain vanilla software raid, then you're SOL if you wanna do anything with it. If you're using any sort of virtualized storage layer (like LVM, VSF, or ZFS), then you can grow it as you need by simply adding drives to the system and using the appropriate command. However, if I may ask, why use RAID5? RAID10 will get you much better performance at a not-as-bad-as-it-seems loss of drive space. RAID5 is really only acceptable for read-heavy, write-light operations IMHO.
Depends on what your using. If your using the plain vanilla software raid, then you're SOL if you wanna do anything with it. If you're using any sort of virtualized storage layer (like LVM, VSF, or ZFS), then you can grow it as you need by simply adding drives to the system and using the appropriate command. However, if I may ask, why use RAID5? RAID10 will get you much better performance at a not-as-bad-as-it-seems loss of drive space. RAID5 is really only acceptable for read-heavy, write-light operations IMHO.
It is mostly a file server. I was thinking of mounting a few partitins to it, but then I decided to raid 1 the OS. Raid 5/6 is cheap for a home job. It also rus a few core services, applications, and VMWare, so the Raid 1 would be best and amanda could back up to vtapes on raid 5 and a tape drive I have.
Yes, you are going exactly where I want you to: LVM. I really have never used it before. My partitions for fixed drives have been fine. Now that I want to set up this raid and make it flexible for future use, it seems like I have to take LVM as well in order to get the max benefit. I had heard that LVM can make data recovery a pain, but this may have been geared towards / being LVM. Are there any down sides to LVM for a NAS raid?
If I set up LVM I am probably going to be hosed anyway since I was going to use JFS. JFS can only grow its FS. So I don't think it would be useful for LVM if I wanted to decrease a LV. Correct?
I didn't want to use XFS since it may lose data in the event of power loss, but the raid 5 write hole is a much bigger risk (I beleive) and am thus getting a nice beefy UPS to email me (I travel for work) and shutdown gracefully.
DISCLAIMER: I found ZFS early on and haven't looked back since, so I'm not quite up to date on other virtualized storage layer technologies. I hear btrfs is supposedly to be an end-all?
I think if you want to be as safe as possible, I'd take a bit of a capacity hit for mirrored storage on a box running ZFS. Set it to scrub maybe weekly, and call it a day. Please glance at the following link for a (tiny little bit biased, but ultimately true) comparison of RAID levels: http://www.miracleas.com/BAARF/RAID5_versus_RAID10.txt
A quote from the above link:
If a drive costs $1000US (and most are far
less expensive than that) then switching from a 4 pair RAID10 array to a 5
drive RAID5 array will save 3 drives or $3000US. What is the cost of
overtime, wear and tear on the technicians, DBAs, managers, and customers
of even a recovery scare? What is the cost of reduced performance and
possibly reduced customer satisfaction? Finally what is the cost of lost
business if data is unrecoverable? I maintain that the drives are FAR
cheaper!
As far as increasing and decreasing logical volumes go, it's always a lot harder to reduce capacity than it is the increase it. For home use, I would recommend hosting everything (backups, share folders) on one behemoth file share, then backup your backups to tape. I would keep your VM's in a separate pool, depending on performance issues, but if it's for home, it'd likely be fine in the same box.
UPS = always a good idea.
Last edited by jim80net; 05-12-2009 at 07:19 AM.
Reason: added Disclaimer
DISCLAIMER: I found ZFS early on and haven't looked back since, so I'm not quite up to date on other virtualized storage layer technologies. I hear btrfs is supposedly to be an end-all?
I think if you want to be as safe as possible, I'd take a bit of a capacity hit for mirrored storage on a box running ZFS. Set it to scrub maybe weekly, and call it a day. Please glance at the following link for a (tiny little bit biased, but ultimately true) comparison of RAID levels: http://www.miracleas.com/BAARF/RAID5_versus_RAID10.txt
A quote from the above link:
If a drive costs $1000US (and most are far
less expensive than that) then switching from a 4 pair RAID10 array to a 5
drive RAID5 array will save 3 drives or $3000US. What is the cost of
overtime, wear and tear on the technicians, DBAs, managers, and customers
of even a recovery scare? What is the cost of reduced performance and
possibly reduced customer satisfaction? Finally what is the cost of lost
business if data is unrecoverable? I maintain that the drives are FAR
cheaper!
As far as increasing and decreasing logical volumes go, it's always a lot harder to reduce capacity than it is the increase it. For home use, I would recommend hosting everything (backups, share folders) on one behemoth file share, then backup your backups to tape. I would keep your VM's in a separate pool, depending on performance issues, but if it's for home, it'd likely be fine in the same box.
UPS = always a good idea.
I was really considering moving to FreeBSD just to take advantage of ZFS. I'm not totally confident in the coding and performance of the FUSE port for linux. The only drawback is that VMWare (or any VM emulator I've found) does not have a port for BSD. (Well, that's not totally true. There is a port for VMWare 3, but it is old.) So I'm stuck with Linux and it's file systems. I'll be sure to check out BTRFS, I've haven't heard of it. I didn't see it offered natively in OpenSuse. I'm actually very close to getting rid of OS 11; there wasn't much QA done. (Another reason for BSD.) So, I'm thinking of setting up Debian (which I have not used yet) for more reliability. Do you know if BTRFS is supported by Debian?
Personally, I use Debian for applications (web, PXE, etc), OpenSolaris for FS, Windows for AD, and Windows and Ubuntu for workstations. I haven't taken the time to learn BSD, so I couldn't speak on it's merits. But use what's best for you...
I'm not too sure about BtrFS, all I know is that it's new and it's still in development, probably best to steer clear for now, unless you've got a fair bit of experience and some storage to play around with.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.