linux-kernel - Re: FEATURE REQUEST: merge MD software raid and LVM in one unique layer.

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] [day] [month] [year] [list]

Message-ID: <f058a9c30705030225s122ffbag54a33aa810996d8f@mail.gmail.com>
Date:	Thu, 3 May 2007 10:25:07 +0100
From:	"Miguel Sousa Filipe" <miguel.filipe@...il.com>
To:	"David Greaves" <david@...eaves.com>
Cc:	david@...g.hm, "Diego Calleja" <diegocg@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: FEATURE REQUEST: merge MD software raid and LVM in one unique layer.

On 5/3/07, David Greaves <david@...eaves.com> wrote:
> david@...g.hm wrote:
> > On Wed, 2 May 2007, Miguel Sousa Filipe wrote:
> >
> >> On 5/2/07, Diego Calleja <diegocg@...il.com> wrote:
> >>>  El Wed, 2 May 2007 20:18:55 +0100, "Miguel Sousa Filipe"
> >>>  <miguel.filipe@...il.com> escribió:
> >>>
> >>> >  I find it high irritanting having two kernel interfaces and two
> >>> >  userland tools that provide the same funcionality, which one should I
> >>> >  use?
> >>>
> >>>  I doubt users care about kernel's design; however the lack of
> >>> unification of  userspace tools is a real problem. Just my 2¢.
>
> >> This is also a problem for any developer who tries to improve
> >> usability in this area by creating some unified userland tools to
> >> manipulate MD & LVM. (Imagining myself implementing some userland tool
> >> to create some "storage devices" + mount points.. doesn't  seem easy
> >> nor fun..).
> >
> > why do you care if the userspace tool that does the resizing makes
> > system calls to one layer or to two layers? how would you know?
>
> Indeed!!
>
> EVMS
>
> http://evms.sourceforge.net/
>
> Enterprise Volume Management System
>
> In order to make the transition to EVMS as smooth as possible, EVMS includes
> compatibility with a number of existing storage and volume management systems.
> Currently, EVMS recognizes:
>
>     * All locally attached disks
>     * DOS-style disk partitions (used extensively on Linux systems)
>     * GPT disk partitions (mainly used on IA-64)
>     * S/390 disk partitions (CDL/LDL)
>     * BSD disk partitions
>     * Macintosh disk partitions
>     * Linux MD/Software-RAID devices
>     * Linux LVM volume groups and logical volumes (versions 1 and 2)
>
> Anything else?
>
> Oh... yes:
>
> In addition to providing compatibility with these existing systems, EVMS also
> provides new functionality that can be built on top of any of the above
> "volumes" that EVMS already recognizes. Features that are currently included are:
>
>     * Bad Block Relocation
>     * Linear Drive Linking
>     * Generic Snapshotting
>
> Enough? or would you like:
> In addition to these volume-level features, the EVMS tools provide convenient
> integration with numerous filesystem tools, to allow tasks such as mkfs and fsck
> directly from the EVMS user interfaces. Currently, the following filesystems are
> supported:
>
>     * Ext2/3
>     * JFS
>     * ReiserFS
>     * XFS
>     * Swap
>     * OCFS2
>     * NTFS
>     * FAT
>
> ??
> Oh, and for the l33t there's a GUI and screenshots...
>
> Of course, in keeping with ZFS, this management layer is all proprietary and
> costs megabucks - or is it GPL, can never remember...
>
> Damn that "irritanting" architecture - keeps us from doing cool things...
>
> Seriously - I hope this is useful ;)
>
> David
>

That was indeed informative, thank you for your reply.
I'll try EVMS sometime soon then.. :D

-- 
Miguel Sousa Filipe
-
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/