|
Replies:
18
-
Last Post:
Jan 2, 2008 3:52 PM
by: cheeney
|
|
|
Posts:
1,174
From:
IL
Registered:
4/27/05
|
|
|
|
Project Proposal: Device Mapper
Posted:
Dec 1, 2007 2:09 AM
|
|
I'd like to propose a project that will investigate support for Device
Mapper facility [0],
similar (or even compatible) to Linux device-mapper facility[1].
While OpenSolaris comes with state of the art native storage features and
capabilities it lacks interoperability with technologies used in other systems
like Linux. For example Linux LVM2 framework[2] is very popular disk management
facility used by default by numerous Linux distributions. LVM2 uses
device-mapper[1]
as a kernel low-level engine and has a set user-land utilities to
manage its entities.
LVM2 interoperability can be very nice supplement to the ext[23] file system
support project suggested recently to this community.
Generic device mapper facility in Solaris will create a foundation for providing
other layers both for interoperability purposes (LVM2, etc) and other Solaris
native uses (think lofi being just a wrapper around device mapper for example).
Initial project team: Cyril Plisko
[0] http://www.genunix.org/wiki/index.php/OpenSolaris_Storage_Developer_Wish_List#Other
[1] http://sources.redhat.com/dm/
[2] http://sources.redhat.com/lvm2/
--
Regards,
Cyril
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
Posts:
581
From:
CZ
Registered:
3/21/06
|
|
|
|
Re: Project Proposal: Device Mapper
Posted:
Dec 3, 2007 12:24 AM
in response to: imp
|
|
Hi Cyril,
Cyril Plisko píše v so 01. 12. 2007 v 12:09 +0200:
> I'd like to propose a project that will investigate support for Device
> Mapper facility [0],
> similar (or even compatible) to Linux device-mapper facility[1].
>
> While OpenSolaris comes with state of the art native storage features and
> capabilities it lacks interoperability with technologies used in other systems
> like Linux. For example Linux LVM2 framework[2] is very popular disk management
> facility used by default by numerous Linux distributions. LVM2 uses
> device-mapper[1]
> as a kernel low-level engine and has a set user-land utilities to
> manage its entities.
>
> LVM2 interoperability can be very nice supplement to the ext[23] file system
> support project suggested recently to this community.
>
> Generic device mapper facility in Solaris will create a foundation for providing
> other layers both for interoperability purposes (LVM2, etc) and other Solaris
> native uses (think lofi being just a wrapper around device mapper for example).
>
> Initial project team: Cyril Plisko
>
Do we have developer's documentation for it, to avoid looking at Linux
source code?
As the second, could be SVM enhanced to support LVM?
Best regards,
Milan
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
1,174
From:
IL
Registered:
4/27/05
|
|
|
|
Re: Project Proposal: Device Mapper
Posted:
Dec 3, 2007 1:16 AM
in response to: jurikm
|
|
On Dec 3, 2007 10:24 AM, Milan Jurik <Milan dot Jurik at sun dot com> wrote:
> Hi Cyril,
>
> Cyril Plisko píše v so 01. 12. 2007 v 12:09 +0200:
> > I'd like to propose a project that will investigate support for Device
> > Mapper facility [0],
> > similar (or even compatible) to Linux device-mapper facility[1].
> >
> > While OpenSolaris comes with state of the art native storage features and
> > capabilities it lacks interoperability with technologies used in other systems
> > like Linux. For example Linux LVM2 framework[2] is very popular disk management
> > facility used by default by numerous Linux distributions. LVM2 uses
> > device-mapper[1]
> > as a kernel low-level engine and has a set user-land utilities to
> > manage its entities.
> >
> > LVM2 interoperability can be very nice supplement to the ext[23] file system
> > support project suggested recently to this community.
> >
> > Generic device mapper facility in Solaris will create a foundation for providing
> > other layers both for interoperability purposes (LVM2, etc) and other Solaris
> > native uses (think lofi being just a wrapper around device mapper for example).
> >
> > Initial project team: Cyril Plisko
> >
>
> Do we have developer's documentation for it, to avoid looking at Linux
> source code?
I don't know yet. That's why the proposal states that its goal is investigation.
I do know, OTOH, that part of the implementation is LGPL covered.
I think it can help us.
>
> As the second, could be SVM enhanced to support LVM?
I have no idea, frankly speaking. I was under impression that
SVM is obsoleted/EOLed, although I may be wrong here.
In any case proposal is for device-mapper, which is an enabler
for LVM, but not the LVM itself.
--
Regards,
Cyril
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
581
From:
CZ
Registered:
3/21/06
|
|
|
|
Re: Project Proposal: Device Mapper
Posted:
Dec 3, 2007 2:17 AM
in response to: imp
|
|
Hi Cyril,
V po, 03. 12. 2007 v 10:16, Cyril Plisko píše:
> On Dec 3, 2007 10:24 AM, Milan Jurik <Milan dot Jurik at sun dot com> wrote:
> > Hi Cyril,
> >
> > Cyril Plisko píše v so 01. 12. 2007 v 12:09 +0200:
> > > I'd like to propose a project that will investigate support for Device
> > > Mapper facility [0],
> > > similar (or even compatible) to Linux device-mapper facility[1].
> > >
> > > While OpenSolaris comes with state of the art native storage features and
> > > capabilities it lacks interoperability with technologies used in other systems
> > > like Linux. For example Linux LVM2 framework[2] is very popular disk management
> > > facility used by default by numerous Linux distributions. LVM2 uses
> > > device-mapper[1]
> > > as a kernel low-level engine and has a set user-land utilities to
> > > manage its entities.
> > >
> > > LVM2 interoperability can be very nice supplement to the ext[23] file system
> > > support project suggested recently to this community.
> > >
> > > Generic device mapper facility in Solaris will create a foundation for providing
> > > other layers both for interoperability purposes (LVM2, etc) and other Solaris
> > > native uses (think lofi being just a wrapper around device mapper for example).
> > >
> > > Initial project team: Cyril Plisko
> > >
> >
> > Do we have developer's documentation for it, to avoid looking at Linux
> > source code?
>
> I don't know yet. That's why the proposal states that its goal is investigation.
> I do know, OTOH, that part of the implementation is LGPL covered.
> I think it can help us.
>
> >
> > As the second, could be SVM enhanced to support LVM?
>
> I have no idea, frankly speaking. I was under impression that
> SVM is obsoleted/EOLed, although I may be wrong here.
> In any case proposal is for device-mapper, which is an enabler
> for LVM, but not the LVM itself.
>
OK, thank you for clarification.
+1 for this proposal
Best regards,
Milan
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
1,582
From:
US
Registered:
6/14/05
|
|
|
|
Re: Project Proposal: Device Mapper
Posted:
Dec 4, 2007 1:20 AM
in response to: imp
To: Communities » storage » discuss
|
|
Would this be one of the tools that might eventually help getting labelling out
of device drivers and filesystems, and into a set of common functions that just
pass back the partition info to the driver (or the size of the reserved area at
the beginning of the slice to the filesystem)?
I've always hated that quite a bit of disk label knowledge is
embedded in drivers and filesystems, rather than in separate support
routines (which could enable smarter or more consistent (between x86 and
SPARC)) handling of trickier cases like logical partitions and so on. To the
extent that drivers could delegate label parsing, partition setup and
corresponding minor device creation to support routines, they'd surely
be simplified. And think about what pcfs has to know about FDISK
partitions: if someone wanted to create a native (not just FUSE) port of a
pre-existing PC filesystem (ntfs, ext2fs, whatever), would it also have
to be burdened with such knowledge?
I can understand that access to media is essential, and has been tweaked
quite a bit. But if that continues to excuse aggregation rather than design,
it will IMO all just collapse under its own weight eventually. And I find
it hard to believe that the present approach is anywhere near as well
layered as it could or should be.
|
|
|
|
|
Posts:
1,174
From:
IL
Registered:
4/27/05
|
|
|
|
Re: Project Proposal: Device Mapper
Posted:
Dec 4, 2007 4:08 AM
in response to: rlhamil
|
|
On Dec 4, 2007 11:20 AM, Richard L. Hamilton <rlhamil at smart dot net> wrote:
> Would this be one of the tools that might eventually help getting labelling out
> of device drivers and filesystems, and into a set of common functions that just
> pass back the partition info to the driver (or the size of the reserved area at
> the beginning of the slice to the filesystem)?
>
> I've always hated that quite a bit of disk label knowledge is
> embedded in drivers and filesystems, rather than in separate support
> routines (which could enable smarter or more consistent (between x86 and
> SPARC)) handling of trickier cases like logical partitions and so on. To the
> extent that drivers could delegate label parsing, partition setup and
> corresponding minor device creation to support routines, they'd surely
> be simplified. And think about what pcfs has to know about FDISK
> partitions: if someone wanted to create a native (not just FUSE) port of a
> pre-existing PC filesystem (ntfs, ext2fs, whatever), would it also have
> to be burdened with such knowledge?
>
> I can understand that access to media is essential, and has been tweaked
> quite a bit. But if that continues to excuse aggregation rather than design,
> it will IMO all just collapse under its own weight eventually. And I find
> it hard to believe that the present approach is anywhere near as well
> layered as it could or should be.
>
Richard,
I pretty much share your feeling about current labeling state
of affair. However, I do not see how this project can address the
problem you are describing in an elegant way.
I am, nonetheless, open to suggestions in this direction.
--
Regards,
Cyril
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
1,174
From:
IL
Registered:
4/27/05
|
|
|
|
Re: Project Proposal: Device Mapper
Posted:
Dec 21, 2007 3:04 AM
in response to: imp
|
|
On Dec 1, 2007 12:09 PM, Cyril Plisko <cyril dot plisko at mountall dot com> wrote:
> I'd like to propose a project that will investigate support for Device
> Mapper facility [0],
> similar (or even compatible) to Linux device-mapper facility[1].
>
Hi,
in case it wasn't obvious I am giving an implicit +1 to this project.
How many other core contributor's votes does project proposal
need to collect in order to be instantiated ?
--
Regards,
Cyril
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Jason J. W. Wil...
jasonjwwilliams@gmai...
|
|
|
|
Re: Project Proposal: Device Mapper
Posted:
Dec 21, 2007 7:56 AM
in response to: imp
|
|
As long as its implemented more stably than Linux's DM.
-J
On 12/21/07, Cyril Plisko <cyril dot plisko at mountall dot com> wrote:
> On Dec 1, 2007 12:09 PM, Cyril Plisko <cyril dot plisko at mountall dot com> wrote:
> > I'd like to propose a project that will investigate support for Device
> > Mapper facility [0],
> > similar (or even compatible) to Linux device-mapper facility[1].
> >
>
> Hi,
>
> in case it wasn't obvious I am giving an implicit +1 to this project.
>
> How many other core contributor's votes does project proposal
> need to collect in order to be instantiated ?
>
> --
> Regards,
> Cyril
> _______________________________________________
> storage-discuss mailing list
> storage-discuss at opensolaris dot org
> http://mail.opensolaris.org/mailman/listinfo/storage-discuss
>
--
Sent from Gmail for mobile | mobile.google.com
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
453
From:
US
Registered:
12/21/05
|
|
|
|
Re: Project Proposal: Device Mapper
Posted:
Dec 21, 2007 8:31 AM
in response to: imp
|
|
Cyril Plisko wrote:
> On Dec 1, 2007 12:09 PM, Cyril Plisko <cyril dot plisko at mountall dot com> wrote:
>
>> I'd like to propose a project that will investigate support for Device
>> Mapper facility [0],
>> similar (or even compatible) to Linux device-mapper facility[1].
>>
>>
>
> Hi,
>
> in case it wasn't obvious I am giving an implicit +1 to this project.
>
> How many other core contributor's votes does project proposal
> need to collect in order to be instantiated ?
>
>
I believe you need 3 in total and no -1s.
Did anyone set a timeout date on this?
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
105
From:
Registered:
3/9/05
|
|
|
|
Re: Project Proposal: Device Mapper
Posted:
Dec 21, 2007 9:51 AM
in response to: imp
|
|
Sorry for the late response. I think I'm unclear as to why we need a
project created for investigative purposes. I would think that if we're
trying to determine feasibility, that can be done outside the scope of a
formal project. The word investigate sort of implies that the project
might not proceed dependent upon the outcome of some investigation and
maybe that's truly the intent of the proposal. Is it possible to clarify
what needs to be investigated and can/should anything be done up front
prior to project instantiation to better ensure success? For me, it's
not entirely clear what I'm voting on.
- John
Cyril Plisko wrote:
> On Dec 1, 2007 12:09 PM, Cyril Plisko <cyril dot plisko at mountall dot com> wrote:
>
>> I'd like to propose a project that will investigate support for Device
>> Mapper facility [0],
>> similar (or even compatible) to Linux device-mapper facility[1].
>>
>>
>
> Hi,
>
> in case it wasn't obvious I am giving an implicit +1 to this project.
>
> How many other core contributor's votes does project proposal
> need to collect in order to be instantiated ?
>
>
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
1,174
From:
IL
Registered:
4/27/05
|
|
|
|
Re: Project Proposal: Device Mapper
Posted:
Dec 21, 2007 11:29 AM
in response to: jforte
|
|
On Dec 21, 2007 7:51 PM, John Forte <John dot Forte at sun dot com> wrote:
> Sorry for the late response. I think I'm unclear as to why we need a
> project created for investigative purposes. I would think that if we're
> trying to determine feasibility, that can be done outside the scope of a
> formal project. The word investigate sort of implies that the project
> might not proceed dependent upon the outcome of some investigation and
> maybe that's truly the intent of the proposal. Is it possible to clarify
> what needs to be investigated and can/should anything be done up front
> prior to project instantiation to better ensure success? For me, it's
> not entirely clear what I'm voting on.
John,
You right, I should have clarify that a little bit more. The purpose of the
investigation is to determine whether the compatibility with Linux
device-mapper can be achieved. The device mapper by itself is quite
useful facility in my opinion. The immediate value, however, is in providing
enough functionality to be able to interoperate with Linux.
What can be done upfront ? That's a good question. I am planning to
prototype the dm facility and use this prototype to see whether I can
get it to access Linux-created devices. Another thing is to check whether
original Linux libdevmapper can be used as is. The library is licensed
under LGPL, so the licensing shouldn't be as issue. There portability of
the code, on the other hand is questionable. So another thing to determine
would be whether to create a native library implementing same API, or
to invest into porting it (lib) over to Solaris.
Does that clear thing up for you ?
--
Regards,
Cyril
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
453
From:
US
Registered:
12/21/05
|
|
|
|
Re: Project Proposal: Device Mapper
Posted:
Dec 21, 2007 12:09 PM
in response to: imp
|
|
Cyril Plisko wrote:
> On Dec 21, 2007 7:51 PM, John Forte <John dot Forte at sun dot com> wrote:
>
>> Sorry for the late response. I think I'm unclear as to why we need a
>> project created for investigative purposes. I would think that if we're
>> trying to determine feasibility, that can be done outside the scope of a
>> formal project. The word investigate sort of implies that the project
>> might not proceed dependent upon the outcome of some investigation and
>> maybe that's truly the intent of the proposal. Is it possible to clarify
>> what needs to be investigated and can/should anything be done up front
>> prior to project instantiation to better ensure success? For me, it's
>> not entirely clear what I'm voting on.
>>
>
> John,
>
> You right, I should have clarify that a little bit more. The purpose of the
> investigation is to determine whether the compatibility with Linux
> device-mapper can be achieved. The device mapper by itself is quite
> useful facility in my opinion. The immediate value, however, is in providing
> enough functionality to be able to interoperate with Linux.
>
> What can be done upfront ? That's a good question. I am planning to
> prototype the dm facility and use this prototype to see whether I can
> get it to access Linux-created devices. Another thing is to check whether
> original Linux libdevmapper can be used as is. The library is licensed
> under LGPL, so the licensing shouldn't be as issue. There portability of
> the code, on the other hand is questionable. So another thing to determine
> would be whether to create a native library implementing same API, or
> to invest into porting it (lib) over to Solaris.
>
> Does that clear thing up for you ?
>
>
I'm okay with a project for a prototype which may never make its way
into the code base.
By the way, having a project accepted by a CG is by no means a guarantee
that it will be
accepted into OpenSolaris. That is a decision for an ARC.
Anyway, +1.
Also, since no one else has piped up about a timeout and this has been
languishing for
some time, lets give it a timeout of Dec 27th. I would have done
earlier, except for the
whole Dec 25th thing...
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
1,174
From:
IL
Registered:
4/27/05
|
|
|
|
Re: Project Proposal: Device Mapper
Posted:
Dec 29, 2007 9:26 AM
in response to: tdh
|
|
On Dec 21, 2007 10:09 PM, Tom Haynes <Thomas dot Haynes at sun dot com> wrote:
>
> Also, since no one else has piped up about a timeout and this has been
> languishing for
> some time, lets give it a timeout of Dec 27th. I would have done
> earlier, except for the
> whole Dec 25th thing...
It looks like this project proposal has needed votes. What's the next step ?
--
Regards,
Cyril
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
453
From:
US
Registered:
12/21/05
|
|
|
|
Re: Project Proposal: Device Mapper
Posted:
Dec 29, 2007 3:38 PM
in response to: imp
|
|
Cyril Plisko wrote:
> On Dec 21, 2007 10:09 PM, Tom Haynes <Thomas dot Haynes at sun dot com> wrote:
>
>> Also, since no one else has piped up about a timeout and this has been
>> languishing for
>> some time, lets give it a timeout of Dec 27th. I would have done
>> earlier, except for the
>> whole Dec 25th thing...
>>
>
> It looks like this project proposal has needed votes. What's the next step ?
>
>
You can assume it is approved. Nothing much will probably happen until
Jan 2nd, when people return from
the holidays....
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
161
From:
US
Registered:
5/25/05
|
|
|
|
Re: Project Proposal: Device Mapper
Posted:
Jan 2, 2008 3:52 PM
in response to: imp
|
|
On 12/29/07 10:26, Cyril Plisko wrote:
> On Dec 21, 2007 10:09 PM, Tom Haynes <Thomas dot Haynes at sun dot com> wrote:
>
>> Also, since no one else has piped up about a timeout and this has been
>> languishing for
>> some time, lets give it a timeout of Dec 27th. I would have done
>> earlier, except for the
>> whole Dec 25th thing...
>>
>
> It looks like this project proposal has needed votes. What's the next step ?
>
>
Congratulation on your project approval ... I'll take up with you
off-line to get the project page created
--jc
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Chris Horne
Chris.Horne@Sun.COM
|
|
|
|
Re: Project Proposal: Device Mapper
Posted:
Dec 21, 2007 10:29 AM
in response to: imp
|
|
To me, the proposal is not clear in regard to the intended scope, or in
its relationship to existing Solaris device management facilities.
I understand wanting new file system support for *basic* media, but the
need to support *amalgamated* media (implemented via Device_Mapper and
LVM2) seems of lower priority.
In terms of scope, is the proposal to make "Device_Mapper" a core
Solaris concept, or is it just there as a shim below the Linux file
system code?
The way that Linux and Solaris deal with devices is different. I am
very interested in 'concepts' that are missing in the Solaris device
management support. For core Solaris, we should focus on the missing
concepts and how to provide an implementation that leads to a coherent
view of devices and their administration.
The broader the intended scope of this proposal, the more concern I
have. I wonder if we would be best served by deferring support for
amalgamated media, concentrateing on file systems mapping to basic
media.
-Chris
Cyril Plisko wrote:
> On Dec 1, 2007 12:09 PM, Cyril Plisko <cyril dot plisko at mountall dot com> wrote:
>
>>I'd like to propose a project that will investigate support for Device
>>Mapper facility [0],
>>similar (or even compatible) to Linux device-mapper facility[1].
>>
>
>
> Hi,
>
> in case it wasn't obvious I am giving an implicit +1 to this project.
>
> How many other core contributor's votes does project proposal
> need to collect in order to be instantiated ?
>
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
1,174
From:
IL
Registered:
4/27/05
|
|
|
|
Re: Project Proposal: Device Mapper
Posted:
Dec 21, 2007 11:57 AM
in response to: Chris Horne
|
|
On Dec 21, 2007 8:29 PM, Chris Horne <Chris dot Horne at sun dot com> wrote:
> To me, the proposal is not clear in regard to the intended scope, or in
> its relationship to existing Solaris device management facilities.
Chris,
Frankly speaking it is not clear to me either. That is why I said
investigating is one of the goals. And that is why I want it to be
a project endorsed by storage community. I am sufficiently motivated
to work on this by myself, with zero visibility to os.org. However,
I do not think it is a right thing to do. I want other people to be able
to participate at the earliest stage possible. (Contrary to recent
example of projects endorsed after integration into ON).
> I understand wanting new file system support for *basic* media, but the
> need to support *amalgamated* media (implemented via Device_Mapper and
> LVM2) seems of lower priority.
This project is not related to file system, at least not directly. I see
no reason to serialize them. And for what it worth, I do not agree
that your prioritisation ("basic" vs. "amalgamated") is correct.
Chances that you'll see mostly "amalgamated" ext3 volumes
in the real world when dual boot with Solaris will be considered.
> In terms of scope, is the proposal to make "Device_Mapper" a core
> Solaris concept, or is it just there as a shim below the Linux file
> system code?
I tend to think it is closer to be a core than to be a shim,
but it is rather hard to say right now.
> The broader the intended scope of this proposal, the more concern I
> have. I wonder if we would be best served by deferring support for
> amalgamated media, concentrateing on file systems mapping to basic
> media.
Once again. It is not about file systems, it is about device mapper.
--
Regards,
Cyril
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
161
From:
US
Registered:
5/25/05
|
|
|
|
Re: Project Proposal: Device Mapper
Posted:
Dec 21, 2007 12:28 PM
in response to: imp
|
|
After the recent discussion I'm inclined to give this a
+1
I think this project, if approved, could be thought of being in an
incubator. It will incubate and grow for a while and then it is ready
for release into the wild (or an OpenSolaris distribution) then it can
go through the regular approval (ARC, et al) processes.
--jc
On 12/21/07 12:57, Cyril Plisko wrote:
> On Dec 21, 2007 8:29 PM, Chris Horne <Chris dot Horne at sun dot com> wrote:
>
>> To me, the proposal is not clear in regard to the intended scope, or in
>> its relationship to existing Solaris device management facilities.
>>
>
>
> Chris,
>
> Frankly speaking it is not clear to me either. That is why I said
> investigating is one of the goals. And that is why I want it to be
> a project endorsed by storage community. I am sufficiently motivated
> to work on this by myself, with zero visibility to os.org. However,
> I do not think it is a right thing to do. I want other people to be able
> to participate at the earliest stage possible. (Contrary to recent
> example of projects endorsed after integration into ON).
>
>
>> I understand wanting new file system support for *basic* media, but the
>> need to support *amalgamated* media (implemented via Device_Mapper and
>> LVM2) seems of lower priority.
>>
>
> This project is not related to file system, at least not directly. I see
> no reason to serialize them. And for what it worth, I do not agree
> that your prioritisation ("basic" vs. "amalgamated") is correct.
> Chances that you'll see mostly "amalgamated" ext3 volumes
> in the real world when dual boot with Solaris will be considered.
>
>
>> In terms of scope, is the proposal to make "Device_Mapper" a core
>> Solaris concept, or is it just there as a shim below the Linux file
>> system code?
>>
>
> I tend to think it is closer to be a core than to be a shim,
> but it is rather hard to say right now.
>
>
>
>> The broader the intended scope of this proposal, the more concern I
>> have. I wonder if we would be best served by deferring support for
>> amalgamated media, concentrateing on file systems mapping to basic
>> media.
>>
>
> Once again. It is not about file systems, it is about device mapper.
>
>
_______________________________________________
storage-discuss mailing list
storage-discuss at opensolaris dot org
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
|
|
|
|
|
Posts:
426
From:
GB
Registered:
3/21/06
|
|
|
|
Re: Project Proposal: Device Mapper
Posted:
Dec 26, 2007 4:14 PM
in response to: imp
To: Communities » storage » discuss
|
|
+1
I think we should support Cyril's work on this investigation.
Cyril wants to run with this - let's see where it takes us.
Cyril needs to reports back on his ideas as
things become clearer, and it will be interesting
to see if & how others can contribute to this effort.
I will also be interested in the implications of
LGPL licensing that Cyril mentions.
http://en.wikipedia.org/wiki/LGPL
Also, if the ext2/3 project produces a successful end result,
that in itself may not be sufficient to give interoperability
with Linux distributions, as many now use LVM2.
So if Linux interoperability is a key requirement,
which other seem to think is the case,
then this Device Mapper project is equally important.
Thanks
Nigel Smith
|
|
|
|
|
