mdadm raid5 with lvm: advantages?

mdadm raid5 with lvm: advantages?

[Richard Grundy]

Hi,

I'm building a new RAID5 array (of 5 1.5 TB drives) with mdadm and
would like to know the benefits of creating an LVM on top of this are
instead of just creating the filesystem on the md directly. I've never
had a problem growing the array and then resizing the filesystem
before and wondered if in this situation the only gain would be lvm
snapshot stuff? I'm planning to use ext4 for this array, if that makes
any difference.

Thanks in advanced,

Rich
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mdadm raid5 with lvm: advantages?

[Steven Haigh]

On 12/01/2011 1:06 AM, Richard Grundy wrote:
> I'm building a new RAID5 array (of 5 1.5 TB drives) with mdadm and
> would like to know the benefits of creating an LVM on top of this are
> instead of just creating the filesystem on the md directly. I've never
> had a problem growing the array and then resizing the filesystem
> before and wondered if in this situation the only gain would be lvm
> snapshot stuff? I'm planning to use ext4 for this array, if that makes
> any difference.

I used lvm over RAID5 on my latest server. It runs the Xen Hypervisor to 
do virtualisation. It was the first project that I have *ever* used lvm 
on. I have to say, I'm quite impressed. I have a volume group that takes 
up the entire RAID5, then split that into logical volumes for each VM.

I guess the bottom line here is what you are using it for. If its one 
massive file dumping ground, then lvm probably won't get you any extra 
features. If you plan to have more things later on than a single 
filesystem, then it might be an advantage to put lvm on there now.

-- 
Steven Haigh

Email: netwiz@crc.id.au
Web: http://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897
Fax: (03) 8338 0299

Re: mdadm raid5 with lvm: advantages?

[Richard Grundy]

It will be used as storage for all my media (audio, videos, apps,
etc), oh and a folder for backups of other computers; sounds like in
my situation lvm wouldn't provide much benefit.

Cheers Rich

On Tue, Jan 11, 2011 at 2:10 PM, Steven Haigh <netwiz@crc.id.au> wrote:
> On 12/01/2011 1:06 AM, Richard Grundy wrote:
>>
>> I'm building a new RAID5 array (of 5 1.5 TB drives) with mdadm and
>> would like to know the benefits of creating an LVM on top of this are
>> instead of just creating the filesystem on the md directly. I've never
>> had a problem growing the array and then resizing the filesystem
>> before and wondered if in this situation the only gain would be lvm
>> snapshot stuff? I'm planning to use ext4 for this array, if that makes
>> any difference.
>
> I used lvm over RAID5 on my latest server. It runs the Xen Hypervisor to do
> virtualisation. It was the first project that I have *ever* used lvm on. I
> have to say, I'm quite impressed. I have a volume group that takes up the
> entire RAID5, then split that into logical volumes for each VM.
>
> I guess the bottom line here is what you are using it for. If its one
> massive file dumping ground, then lvm probably won't get you any extra
> features. If you plan to have more things later on than a single filesystem,
> then it might be an advantage to put lvm on there now.
>
> --
> Steven Haigh
>
> Email: netwiz@crc.id.au
> Web: http://www.crc.id.au
> Phone: (03) 9001 6090 - 0412 935 897
> Fax: (03) 8338 0299
>

Re: mdadm raid5 with lvm: advantages?

[Jan Kasprzak]

Richard Grundy wrote:
: Hi,
: 
: I'm building a new RAID5 array (of 5 1.5 TB drives) with mdadm and
: would like to know the benefits of creating an LVM on top of this are
: instead of just creating the filesystem on the md directly. I've never
: had a problem growing the array and then resizing the filesystem
: before and wondered if in this situation the only gain would be lvm
: snapshot stuff? I'm planning to use ext4 for this array, if that makes
: any difference.

	The disadvantage of lvm over md is that with LV filesystems
usually cannot see the physical layout and determine the correct
level of parallelism (like swidth in XFS, stripe in ext4).

-Yenya

-- 
| Jan "Yenya" Kasprzak  <kas at {fi.muni.cz - work | yenya.net - private}> |
| GPG: ID 1024/D3498839      Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/    Journal: http://www.fi.muni.cz/~kas/blog/ |
Please don't top post and in particular don't attach entire digests to your
mail or we'll all soon be using bittorrent to read the list.     --Alan Cox
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mdadm raid5 with lvm: advantages?

[CoolCold]

On Tue, Jan 11, 2011 at 5:16 PM, Jan Kasprzak <kas@fi.muni.cz> wrote:
> Richard Grundy wrote:
> : Hi,
> :
> : I'm building a new RAID5 array (of 5 1.5 TB drives) with mdadm and
> : would like to know the benefits of creating an LVM on top of this are
> : instead of just creating the filesystem on the md directly. I've never
> : had a problem growing the array and then resizing the filesystem
> : before and wondered if in this situation the only gain would be lvm
> : snapshot stuff? I'm planning to use ext4 for this array, if that makes
> : any difference.
>
>        The disadvantage of lvm over md is that with LV filesystems
> usually cannot see the physical layout and determine the correct
> level of parallelism (like swidth in XFS, stripe in ext4).
XFS (xfsprogs) does this without any problems (for me at least)

>
> -Yenya
>
> --
> | Jan "Yenya" Kasprzak  <kas at {fi.muni.cz - work | yenya.net - private}> |
> | GPG: ID 1024/D3498839      Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
> | http://www.fi.muni.cz/~kas/    Journal: http://www.fi.muni.cz/~kas/blog/ |
> Please don't top post and in particular don't attach entire digests to your
> mail or we'll all soon be using bittorrent to read the list.     --Alan Cox
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Best regards,
[COOLCOLD-RIPN]
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mdadm raid5 with lvm: advantages?

[Zdenek Kaspar]

Dne 11.1.2011 15:06, Richard Grundy napsal(a):
> Hi,
> 
> I'm building a new RAID5 array (of 5 1.5 TB drives) with mdadm and
> would like to know the benefits of creating an LVM on top of this are
> instead of just creating the filesystem on the md directly. I've never
> had a problem growing the array and then resizing the filesystem
> before and wondered if in this situation the only gain would be lvm
> snapshot stuff? I'm planning to use ext4 for this array, if that makes
> any difference.
> 
> Thanks in advanced,
> 
> Rich
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Really depends on your needs..

It makes sense to use LVM for virtualization and iSCSI to get rid of big
file images (unwanted fs overhead/fragmentation). But yes, in some use
cases this is OK.

If you don't need snapshots or whatever LVM feature, then go the
simplest way - no LVM.

HTH, Z.

Re: mdadm raid5 with lvm: advantages?

[Roberto Spadim]

like email subject tell: advantages?

lvm suport - snapshots



2011/1/11 Zdenek Kaspar <zkaspar82@gmail.com>:
> Dne 11.1.2011 15:06, Richard Grundy napsal(a):
>> Hi,
>>
>> I'm building a new RAID5 array (of 5 1.5 TB drives) with mdadm and
>> would like to know the benefits of creating an LVM on top of this are
>> instead of just creating the filesystem on the md directly. I've never
>> had a problem growing the array and then resizing the filesystem
>> before and wondered if in this situation the only gain would be lvm
>> snapshot stuff? I'm planning to use ext4 for this array, if that makes
>> any difference.
>>
>> Thanks in advanced,
>>
>> Rich
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> Really depends on your needs..
>
> It makes sense to use LVM for virtualization and iSCSI to get rid of big
> file images (unwanted fs overhead/fragmentation). But yes, in some use
> cases this is OK.
>
> If you don't need snapshots or whatever LVM feature, then go the
> simplest way - no LVM.
>
> HTH, Z.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Roberto Spadim
Spadim Technology / SPAEmpresarial
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mdadm raid5 with lvm: advantages?

[Roman Mamedov]

[-- Attachment #1: Type: text/plain, Size: 657 bytes --]

On Tue, 11 Jan 2011 19:36:30 +0100
Zdenek Kaspar <zkaspar82@gmail.com> wrote:

> It makes sense to use LVM for virtualization and iSCSI to get rid of big
> file images (unwanted fs overhead/fragmentation). But yes, in some use
> cases this is OK.

Since you mentioned fragmentation - there are ways to both make sparse file
images, and to defragment them when needed (on some filesystems like XFS and
btrfs). But when using LVM instead of file images, the user has neither: LVM
can't have sparse LVs, and it can't (easily) defragment an LV that is
fragmented over one or several PVs. Or am I missing something here?

-- 
With respect,
Roman

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: mdadm raid5 with lvm: advantages?

[Roy Keene]

Roman,

 	LVM supports both sparse LVs (--virtualsize) and defragmentation 
(though as you say it's not currently easy -- I started writing a script 
to handle it but it's not a big enough problem that I've ever actually 
wanted to use the script, still a general purpose "lvdefrag" could be 
written).

Thanks,
 	Roy Keene

On Tue, 11 Jan 2011, Roman Mamedov wrote:

> On Tue, 11 Jan 2011 19:36:30 +0100
> Zdenek Kaspar <zkaspar82@gmail.com> wrote:
>
>> It makes sense to use LVM for virtualization and iSCSI to get rid of big
>> file images (unwanted fs overhead/fragmentation). But yes, in some use
>> cases this is OK.
>
> Since you mentioned fragmentation - there are ways to both make sparse file
> images, and to defragment them when needed (on some filesystems like XFS and
> btrfs). But when using LVM instead of file images, the user has neither: LVM
> can't have sparse LVs, and it can't (easily) defragment an LV that is
> fragmented over one or several PVs. Or am I missing something here?
>
> -- 
> With respect,
> Roman
>

Re: mdadm raid5 with lvm: advantages?

[Zdenek Kaspar]

Dne 11.1.2011 19:49, Roman Mamedov napsal(a):
> On Tue, 11 Jan 2011 19:36:30 +0100
> Zdenek Kaspar <zkaspar82@gmail.com> wrote:
> 
>> It makes sense to use LVM for virtualization and iSCSI to get rid of big
>> file images (unwanted fs overhead/fragmentation). But yes, in some use
>> cases this is OK.
> 
> Since you mentioned fragmentation - there are ways to both make sparse file
> images, and to defragment them when needed (on some filesystems like XFS and
> btrfs). But when using LVM instead of file images, the user has neither: LVM
> can't have sparse LVs, and it can't (easily) defragment an LV that is
> fragmented over one or several PVs. Or am I missing something here?

Yes, some filesystems can solve fragmentation issue. But if there's no
good reason to have images directly on fs, then no need to waste
performance (even if it's just 5%).

I think you have options to move PE's, but it's tricky and it's better
to avoid such allocations in first place..

HTH, Z.