linux-kernel - Re: [RFC] LVM/RAID/FS integration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <p73myyj3xr3.fsf@bingen.suse.de>
Date:	29 Jun 2007 11:39:44 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	"Kent Overstreet" <kent.overstreet@...il.com>
Cc:	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] LVM/RAID/FS integration

"Kent Overstreet" <kent.overstreet@...il.com> writes:
> 
> Basically, the order we want is fs -> raid -> lvm. Given a set of
> identical drives, we want LVM to handle them separately and divide
> them up into LVs identically; then corresponding LVs are raided
> together. We might have a raid5 volume and a raid1 volume, each of
> which can be resized independently. The FS then makes use of both of
> them, putting metadata and frequently used data on the raid1 and
> everything else on the raid5 (btrfs, as I understand it, will be able
> to do this sort of thing eventually).

XFS can do it already using its realtime volume feature. It keeps the
metadata on the original device and puts the data on another device.
The log can be also on another device (but other file systems support
that too)

People often complain about the code size and complexity
of XFS, but it actually implements a lot of functionality
other file systems don't have in there.

Arguably it's all not too easy to configure and a little awkward to
have upto 3 LVs per fs.

And there is no concept of "frequently used data" (which would be
probably hard anyways; how would you move data if it becomes
frequently used) Out of tree XFS actually supports that using DMAPI
and an external manager for automatic swapping of files to tape
robots, but you probably don't want to go this way. DMAPI is pretty
ugly. 

> The trouble is it's completely impractical with current tools; we need
> tighter integration between md and LVM. 

The current direction seems to be to slowly duplicate all MD
functionality in DM, but then there were also some movements
to add a little volume manager to MD. We'll see who wins.
They both move relatively slowly.

> throw out my ideas before I get too far in. Thoughts?

Some nicer high level userland utilities who know how to integrate all
this would be probably a good idea. 

That seems to be the main appeal of ZFS anyways --
simpler user interfaces.

-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/