11:12 p.m.
Or maybe they are playing devicemapper tricks that I've never
even
suspected...
Very interesting, and very worth watching...
So apparently... You no longer need unionfs to have a union.
Very interesting... (if my guestimation and being too lazy to read up on
devicemapper are not leading to my misunderstanding)
-jdog
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
1:22 p.m.
New subject: devicemapper and stateless? (was Re: who needs unionfs!, was Re: experimental unionfs and initramfs code)
On Mon, 2006-04-24 at 21:12 -0700, Jane Dogalt wrote:
> Or maybe they are playing devicemapper tricks that I've
never even
> suspected...
>
> Very interesting, and very worth watching...
So apparently... You no longer need unionfs to have a union.
Very interesting... (if my guestimation and being too lazy to read up on
devicemapper are not leading to my misunderstanding)
I just saw this go by on planet.fedoraproject.org::
http://blogs.gnome.org/view/markmc/2006/04/25/0
notting or jeremy: Is markmc working on something like this as part of
stateless or is the devicemapper work he's doing totally unrelated?
Is there anyway to stay abreast of what's currently happening for
stateless? Working on liveCD stuff becomes something of a moving target
if we don't know what possibilities are actively seeing work in the
underlying infrastructure.
-Toshio
1:33 p.m.
New subject: devicemapper and stateless? (was Re: who needs unionfs!, was Re: experimental unionfs and initramfs code)
Toshio Kuratomi (toshio(a)tiki-lounge.com) said:
> > Or maybe they are playing devicemapper tricks that
I've never even
> > suspected...
> >
> > Very interesting, and very worth watching...
>
> So apparently... You no longer need unionfs to have a union.
>
> Very interesting... (if my guestimation and being too lazy to read up on
> devicemapper are not leading to my misunderstanding)
>
I just saw this go by on planet.fedoraproject.org::
http://blogs.gnome.org/view/markmc/2006/04/25/0
notting or jeremy: Is markmc working on something like this as part of
stateless or is the devicemapper work he's doing totally unrelated?
It's related, but it's not part of the readonly-root support. Using
something like device-mapper for that means you'd have to use a block
device.
What LFS appears to be doing is creating a sparse loop device on tmpfs,
and using that as the block layer. It's a interesting idea, and bears
investigation.
Bill
1:37 p.m.
New subject: devicemapper and stateless? (was Re: who needs unionfs!, was Re: experimental unionfs and initramfs code)
Bill Nottingham (notting(a)redhat.com) said:
> I just saw this go by on planet.fedoraproject.org::
> http://blogs.gnome.org/view/markmc/2006/04/25/0
>
> notting or jeremy: Is markmc working on something like this as part of
> stateless or is the devicemapper work he's doing totally unrelated?
It's related, but it's not part of the readonly-root support. Using
something like device-mapper for that means you'd have to use a block
device.
What LFS appears to be doing is creating a sparse loop device on tmpfs,
and using that as the block layer. It's a interesting idea, and bears
investigation.
However, one of the downsides of this approach is it (essentially) makes
the whole root filesystem read-write, which loses some of the benefits
of readonly-root (and makes it a whole lot easier to DoS yourself.)
Bill
3:36 p.m.
New subject: devicemapper and stateless? (was Re: who needs unionfs!, was Re: experimental unionfs and initramfs code)
--- Bill Nottingham <notting(a)redhat.com> wrote:
Bill Nottingham (notting(a)redhat.com) said:
> > I just saw this go by on planet.fedoraproject.org::
> > http://blogs.gnome.org/view/markmc/2006/04/25/0
> >
> > notting or jeremy: Is markmc working on something like this as part of
> > stateless or is the devicemapper work he's doing totally unrelated?
>
> It's related, but it's not part of the readonly-root support. Using
> something like device-mapper for that means you'd have to use a block
> device.
>
> What LFS appears to be doing is creating a sparse loop device on tmpfs,
> and using that as the block layer. It's a interesting idea, and bears
> investigation.
However, one of the downsides of this approach is it (essentially) makes
the whole root filesystem read-write, which loses some of the benefits
of readonly-root (and makes it a whole lot easier to DoS yourself.)
This is basically just an alternate implementation of unionfs. I asked a while
back what the RH kernel developers thought as far as that, and apparently dm is
the implementation they consider worthwhile.
I'm currently trying to ping Jeremy Huntwork regarding whats going on with the
LFS livecd init code. I.e. why the move away from squashfs to ext2. Is that a
limitation of the dm union/overlay/snapshot implementation, or was there
another reason.
Does anyone here know off the top of their heads if enough of the dm kernel
stuff is already in place in fc5 to do this already?
I know that complexity can be a bad thing, but I'd like to see livecd
generating tools give as much flexibility as can be reasonably modularized by
the generator. I.e. I think a good generator, given the read-only-root infra
provided by stateless, should give both that as an option, and a union
implementation (or two) as options.
Since you can set maxsize on tmpfs, using a writable root overlay IMO is a very
beneficial feature (at least as an option). Clearly by the large number of
livecd implementations that already do this with unionfs+squashfs, I don't
think the risks involved with it outweigh the benefits.
And in general, having the overlay/union infrastructure opens up a plethora of
funtionality options. I.e. slices of the union coming from disk, flash,
network...
-jdog
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
4:43 p.m.
New subject: devicemapper and stateless? (was Re: who needs unionfs!, was Re: experimental unionfs and initramfs code)
Jane Dogalt (jdogalt(a)yahoo.com) said:
> However, one of the downsides of this approach is it
(essentially) makes
> the whole root filesystem read-write, which loses some of the benefits
> of readonly-root (and makes it a whole lot easier to DoS yourself.)
This is basically just an alternate implementation of unionfs.
It's not 100% the same, though - with dm, you're operating at the
block device level, so you have to add the copy-on-write device for the whole
block device (i.e., the entire filesystem.)
Since unionfs is a filesystem, it can theoretically be spliced in
at any level of the tree you want, thereby keeping most of the
filesystem truly read-only.
Bill
6569
days inactive
6569
days old
livecd@lists.fedoraproject.org
5 comments
3 participants
participants (3)
-
Bill Nottingham -
Jane Dogalt -
Toshio Kuratomi