Re: device mapper integrated loops - and one more year !

Re: device mapper integrated loops - and one more year !

[devzero]

Hello !

after desparately seeking for a solution to have more than 256 loop devices (for a huge cd-rom server), i have recently come across dm-loop, which looks very promising (to replace loop.c)

can i have more than 256 devices which this?

our cd-rom server is going to have more than 256 iso-images soon and i need to upgrade to a more recent OS, anyway, so this won`t be a problem that dm-loop is so brand new.

but - any timeline for dm-loop mainline inclusion ?

should i wait for 2.6.19 or 2.6.20 ?

is it already useable with less recent kernels, i.e. can i download dm-loop patch and recent dmsetup tool and use with older kernel ?

i really would like to give it a try - no problem if there are still bugs inside, because i`d happily test and report if there are bugs left.

regards
Roland K.
systems engineer


_______________________________________________________________________
Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos.
Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222

Re: Re: device mapper integrated loops - and one more year !

[Bryn M. Reeves]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

devzero@web.de wrote:
> Hello !
> 
> after desparately seeking for a solution to have more than 256 loop
> devices (for a huge cd-rom server), i have recently come across
> dm-loop, which looks very promising (to replace loop.c)
> 
> can i have more than 256 devices which this?

Hi Roland,

Yes, dm-loop will support as many loop devices as device-mapper can allow.

> our cd-rom server is going to have more than 256 iso-images soon and
> i need to upgrade to a more recent OS, anyway, so this won`t be a 
> problem that dm-loop is so brand new.
> 
> but - any timeline for dm-loop mainline inclusion ?
> 
> should i wait for 2.6.19 or 2.6.20 ?

There isn't a fixed timeline. We are currently working to improve the
lookup code - the prototype patch uses a linear search which doesn't
scale well for large/fragmented image files. I have some tests running
at the moment and we hope to have something soon - the results so far
are good, it's just a case of selecting between a couple of different
methods.

The changes dm-loop requires in device-mapper core are pretty minor and
have already been merged in 2.6.19, so it's just the dm-loop patch
itself remaining.

> is it already useable with less recent kernels, i.e. can i download
> dm-loop patch and recent dmsetup tool and use with older kernel ?

This should work fine - there are a couple of known issues with the
existing patch, but unless you are using large images (>2G), or have a
severely fragmented filesystem you shouldn't run into these.

I'll see if we can get a revised version of the current patch for wider
testing in the next couple of weeks - let me know if you would be
interested in trying this out.

Thanks,

Bryn.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFFY2uJ6YSQoMYUY94RArTwAJwMmCJbTajxmX6Q/ps545zbgvJJOACg28NP
A+F6CtqcHH0fOG9lq2XQw/8=
=CzES
-----END PGP SIGNATURE-----

Re: Re: device mapper integrated loops - and one more year !

[Roland PJ]

Hi Bryn

Just to avoid confusion, this is a different Roland from the original query.

Looking at 
http://www.kernel.org/pub/linux/kernel/people/agk/patches/2.6/editing/dm-loop.patch

+			if (!cur_block)
+				goto bad_bmap;

...

+bad_bmap:
+	DMERR("Loopfile has holes");
+	dump_extent_map(map);

Does this mean that dm-loop does not support sparse loop-back files?

Also, it seems that the approach with dm-loop is that you sniff the (current?) file mapping onto its underlying block device. What happens if the loopback file is modified, or the file system hosting the loopback file does some re-arranging? (I might be way off-tack here - this was a first impression of the code).

I'd be interested in comparing dm-loop to vanilla loop which we currently use.

Regards
Roland #2


>  
>

Re: Re: device mapper integrated loops - and one more year !

[Bryn M. Reeves]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roland PJ wrote:
> Hi Bryn
> 
> Just to avoid confusion, this is a different Roland from the original
> query.

Hi Roland,

Noted ;)

> Does this mean that dm-loop does not support sparse loop-back files?

This version doesn't, no. It's not hard to add this though, although it
does have some implications if they are used. We've had some discussions
over whether this is necessary/desirable - is this something you'd like
to see?

> Also, it seems that the approach with dm-loop is that you sniff the
> (current?) file mapping onto its underlying block device. What happens
> if the loopback file is modified, or the file system hosting the
> loopback file does some re-arranging? (I might be way off-tack here -
> this was a first impression of the code).

You'll find this in loop_get_file():

+	/*
+	 * We overload the S_SWAPFILE flag for loop targets because
+	 * it provides the same no-truncate semantics we require, and holding
+	 * onto i_sem is no longer an option.
+	 */
+	mutex_lock(&inode->i_mutex);
+	inode->i_flags |= S_SWAPFILE;
+	mutex_unlock(&inode->i_mutex);

The bmap approach is also used for swapfiles (mm/swapfile.c) - the
S_SWAPFILE inode flag was added in 2.6.16 when the changeover to mutexes
happened.

> I'd be interested in comparing dm-loop to vanilla loop which we
> currently use.
> 

There are patches to dmsetup that allow it to be called as "losetup" or
"dmlosetup", providing the same options as the regular version, so it
should be straightforward to compare.

Regards,
Bryn.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFFY4nE6YSQoMYUY94RAuFyAJ9heEQvTZZ7dEkaIXQ9nxFy7mDx+gCfTozW
FusS8of73r2GfGTchFWRvdc=
=Eisk
-----END PGP SIGNATURE-----

Re: Re: device mapper integrated loops - and one more year !

[Roland Paterson-Jones]

Hi Bryn

Bryn M. Reeves wrote:

>>Does this mean that dm-loop does not support sparse loop-back files?
>>    
>>
>
>This version doesn't, no. It's not hard to add this though, although it
>does have some implications if they are used. We've had some discussions
>over whether this is necessary/desirable - is this something you'd like
>to see?
>  
>
We very much need sparse files for our use-case (fairly dynamically 
setting up (fake) devices on demand). Sparse files save time to copy, 
for example.

Would you do this by using file ops to lazily fill holes on first write? 
Is this compatible with S_SWAPFILE? For read purposes, holes can be 
mapped to zero device, I presume.

>The bmap approach is also used for swapfiles (mm/swapfile.c) - the
>S_SWAPFILE inode flag was added in 2.6.16 when the changeover to mutexes
>happened.
>  
>
Ah. I did see that - should have made the connection. So which file 
systems support (obey?) S_SWAPFILE?

I much prefer the approach of mapping to underlying device, cos it 
sidesteps the file/page cache (loopback causes OOM!). The other annoying 
thing about loopback is that it re-nices itself to super-low (should 
that be high?) priority, so we can starve other system daemons by 
banging on the loopback device.

>There are patches to dmsetup that allow it to be called as "losetup" or
>"dmlosetup", providing the same options as the regular version, so it
>should be straightforward to compare.
>  
>
Cool. Where can I get a patch to play with? I presume device-mapper 
plug-ins can be compiled as modules?

Regards
Roland #2

Re: Re: device mapper integrated loops - and one more year !

[Bryn M. Reeves]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Roland Paterson-Jones wrote:
> We very much need sparse files for our use-case (fairly dynamically
> setting up (fake) devices on demand). Sparse files save time to copy,
> for example.
> 
> Would you do this by using file ops to lazily fill holes on first write?
> Is this compatible with S_SWAPFILE? For read purposes, holes can be
> mapped to zero device, I presume.

That's what I figured - lazy allocation seems to be the main reason that
sparse files are desirable.

The problem with sparse files is that they make us do something that
dm-loop is explicitly trying to avoid - calling into the filesystem at
I/O time.

There are two ways we can address this. The dm-loop target needs a
non-bmap based fallback for filesystems that can't use direct mapping
anyway (e.g. network filesystems).

We can either revert to this mechanism entirely for sparse files (means
we get many of the drawbacks of regular /dev/loopN), or try to support
mixed extent types. That's had some thought & discussion but we don't
have an implementation ready yet.

> Ah. I did see that - should have made the connection. So which file
> systems support (obey?) S_SWAPFILE?

Currently this is handled in the VFS. Currently the only filesystem that
explicitly checks for S_SWAPFILE is NFS. Filesystems that support online
defragmentation will need to be aware of this flag.

> I much prefer the approach of mapping to underlying device, cos it
> sidesteps the file/page cache (loopback causes OOM!). The other annoying
> thing about loopback is that it re-nices itself to super-low (should
> that be high?) priority, so we can starve other system daemons by
> banging on the loopback device.

This is really the motivation for dm-loop: avoiding unpredictable memory
allocation at I/O time and the need for a per-device kernel thread. It
also ends up simplifying the code a great deal. Early figures on
performance are also suggesting wins in that area.

>> There are patches to dmsetup that allow it to be called as "losetup" or
>> "dmlosetup", providing the same options as the regular version, so it
>> should be straightforward to compare.
>>  
>>
> Cool. Where can I get a patch to play with? I presume device-mapper
> plug-ins can be compiled as modules?

The patch currently on kernel.org uses a table format like this:
<start> <len> loop <path> <offset>

So losetup /dev/loop0 /tmp/file
  becomes roughly
dmsetup create loop0 --table "0 N loop /tmp/file 0"
  --table option is now in cvs; else use stdin
  N is the <filesize_in_bytes>/512
  make file a multiple of your page size & fs block size

If your dmsetup is recent enough to have the --table option.

I was just digging out the dmlosetup patch when I noticed it's already
present in recent CVS - if you build dmsetup from there, you should be
able to symlink dmsetup as losetup/dmlosetup and call it like the
regular version.

Regards,
Bryn.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iD8DBQFFZMMn6YSQoMYUY94RAvkPAKCWNrp2VghDpu1qd7nC2J/OgwQF+gCcCjvV
3PbJcCxOqZIpteMsNKht3Js=
=B/b2
-----END PGP SIGNATURE-----

Re: Re: device mapper integrated loops - and one more year !

[Roland Paterson-Jones]

Bryn M. Reeves wrote:

>Roland Paterson-Jones wrote:
>  
>
>>... sparse files ...
>>
>>Would you do this by using file ops to lazily fill holes on first write?
>>Is this compatible with S_SWAPFILE? For read purposes, holes can be
>>mapped to zero device, I presume.
>>    
>>
>
>That's what I figured - lazy allocation seems to be the main reason that
>sparse files are desirable.
>
>The problem with sparse files is that they make us do something that
>dm-loop is explicitly trying to avoid - calling into the filesystem at
>I/O time.
>  
>
I can live with that, as long as it's only a first-write phenomenon. 
I.e. first-write of a hole uses file-ops, then sniffs the underlying 
device mapping for subsequent ops. Although I guess this could cause the 
same OOM regime for a lot of writes on an initially sparse file (or is 
this exacerbated by loopbacks elevated priority?).

>There are two ways we can address this. The dm-loop target needs a
>non-bmap based fallback for filesystems that can't use direct mapping
>anyway (e.g. network filesystems).
>
>We can either revert to this mechanism entirely for sparse files (means
>we get many of the drawbacks of regular /dev/loopN), or try to support
>mixed extent types. That's had some thought & discussion but we don't
>have an implementation ready yet.
>  
>
I'd be very much in favour of a lazy mixed approach that converges 
towards device-only access with substantial use. Otherwise I think I'm 
back where I started.

>
>The patch currently on kernel.org uses a table format like this:
><start> <len> loop <path> <offset>
>  
>
Thanks. I'll play ;)

Roland

Re: Re: device mapper integrated loops - and one more year !

[devzero]

Hello Bryn, 


>I'll see if we can get a revised version of the current patch for wider
>testing in the next couple of weeks - let me know if you would be
>interested in trying this out.

not sure if i sent a reply to this or have missed this -  but, yes - i`m still interested very much in using dm-loop !

is there anything new with this?
do i have to expect issues with files >2gb ? (i need to loopback mount dvd iso-images)

is there a download url for the latest dm-loop patch so i can do some tests and report feedback ?

i couldn`t find it at http://sources.redhat.com/cgi-bin/cvsweb.cgi/device-mapper/?cvsroot=dm  and i`m not sure if i should take that one from http://kernel.org/pub/linux/kernel/people/agk/patches/2.6/

TIA
roland



> Hello !
> 
> after desparately seeking for a solution to have more than 256 loop
> devices (for a huge cd-rom server), i have recently come across
> dm-loop, which looks very promising (to replace loop.c)
> 
> can i have more than 256 devices which this?

Hi Roland,

Yes, dm-loop will support as many loop devices as device-mapper can allow.

> our cd-rom server is going to have more than 256 iso-images soon and
> i need to upgrade to a more recent OS, anyway, so this won`t be a 
> problem that dm-loop is so brand new.
> 
> but - any timeline for dm-loop mainline inclusion ?
> 
> should i wait for 2.6.19 or 2.6.20 ?

There isn't a fixed timeline. We are currently working to improve the
lookup code - the prototype patch uses a linear search which doesn't
scale well for large/fragmented image files. I have some tests running
at the moment and we hope to have something soon - the results so far
are good, it's just a case of selecting between a couple of different
methods.

The changes dm-loop requires in device-mapper core are pretty minor and
have already been merged in 2.6.19, so it's just the dm-loop patch
itself remaining.

> is it already useable with less recent kernels, i.e. can i download
> dm-loop patch and recent dmsetup tool and use with older kernel ?

This should work fine - there are a couple of known issues with the
existing patch, but unless you are using large images (>2G), or have a
severely fragmented filesystem you shouldn't run into these.

I'll see if we can get a revised version of the current patch for wider
testing in the next couple of weeks - let me know if you would be
interested in trying this out.

Thanks,

Bryn.
__________________________________________________________________________
Erweitern Sie FreeMail zu einem noch leistungsstärkeren E-Mail-Postfach!		
Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131