* mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed
@ 2012-07-12 14:28 Stevie Trujillo
2012-07-12 15:16 ` Steven J. Magnani
0 siblings, 1 reply; 9+ messages in thread
From: Stevie Trujillo @ 2012-07-12 14:28 UTC (permalink / raw)
To: OGAWA Hirofumi, linux-kernel
Hello,
I was trying to create a bootdisk to update my BIOS, and accidentially
made a 512byte image with only the FreeDOS header in it.
( Linux 3.4.4 )
# mount -o loop dosdisk.img /tmp
^C^C^C
It uses 100% CPU and doesn't listen to me when I do ^C, kill -9 etc. I
think this means it's stuck in the kernel?
Here is the base64 encoded image (use base64 -d command to unpack it).
6zyQRnJlZURPUyAAAgEBAALgAEAL8AkAEgACAAAAAAAAAAAAAAApOATF6E5PIE5BTUUgICAgRkFU
MTIgICD6/DHAjti9AHy44B+OwInuie+5AAHzpepefOAfAABgAI7YjtCNZqD7gH4k/3UDiFYkx0bA
EADHRsIBAOjpAEZyZWVET1MAi3Yci34eA3YOg9cAiXbSiX7UikYQmPdmFgHGEdeJdtaJftiLXgux
BdPri0YRMdL384lG0AHGg9cAiXbaiX7ci0bWi1bYi37QxF5a6JsAci/Eflq5CwC+8X1X86ZfJotF
GnQLg8cgJoA9AHXncllQxF5ai34Wi0bSi1bU6GsAWHJGHgeOXly/ACCricYB9gHG0e6tcwSxBNPo
gOQPPfgPcugxwKsOH8ReWr4AIK0JwHQkSEiLfg2B5/8A9+cDRtoTVtzoJABz5egXACBlcnIAMOTN
Fs0Zil4k/25aMdu0Ds0QXqxWPAB188NWiUbIiVbKjEbGiV7EtEG7qlWKViSE0nQZzRNyFdHpgdtU
qnUNjXbAiV7MiV7OtELrLItOyItWyopGGPZmGpH38ZL2dhiJ0YjGhunQydDJikYYKOD+xAjhxF7E
uAECilYkzRNzBjDkzRProotGC/Z2wAFGxoNGyAGDVsoAT3XqjkbGXsNLRVJORUwgIFNZUwAAVao=
--
Stevie Trujillo
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed
2012-07-12 14:28 mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed Stevie Trujillo
@ 2012-07-12 15:16 ` Steven J. Magnani
2012-07-12 19:21 ` OGAWA Hirofumi
0 siblings, 1 reply; 9+ messages in thread
From: Steven J. Magnani @ 2012-07-12 15:16 UTC (permalink / raw)
To: Stevie Trujillo; +Cc: OGAWA Hirofumi, linux-kernel
On Thu, 2012-07-12 at 16:28 +0200, Stevie Trujillo wrote:
> Hello,
>
> I was trying to create a bootdisk to update my BIOS, and accidentially
> made a 512byte image with only the FreeDOS header in it.
>
> ( Linux 3.4.4 )
> # mount -o loop dosdisk.img /tmp
> ^C^C^C
> It uses 100% CPU and doesn't listen to me when I do ^C, kill -9 etc. I
> think this means it's stuck in the kernel?
Here is the stack trace I get for the mount process:
[root@telezart smagnani]# cat /proc/1334/stack
[<ffffffff81077a5a>] __cond_resched+0x2a/0x40
[<ffffffff8110c4bb>] find_lock_page+0x3b/0x80
[<ffffffff8110cbaf>] find_or_create_page+0x3f/0xb0
[<ffffffff8119a692>] __getblk+0xf2/0x2a0
[<ffffffff8119a893>] __bread+0x13/0xb0
[<ffffffffa00fd1fe>] fat__get_entry+0x14e/0x220 [fat]
[<ffffffffa00fd596>] fat_get_short_entry+0x66/0xc0 [fat]
[<ffffffffa00ff765>] fat_subdirs+0x55/0x80 [fat]
[<ffffffffa0103d30>] fat_fill_super+0x810/0xa80 [fat]
[<ffffffffa00e821a>] vfat_fill_super+0x1a/0x20 [vfat]
[<ffffffff8116d61b>] mount_bdev+0x1cb/0x210
[<ffffffffa00e81f5>] vfat_mount+0x15/0x20 [vfat]
[<ffffffff8116e410>] mount_fs+0x20/0xd0
[<ffffffff81186e4f>] vfs_kern_mount+0x6f/0x100
[<ffffffff81187804>] do_kern_mount+0x54/0x110
[<ffffffff811891d6>] do_mount+0x306/0x8b0
[<ffffffff811898cd>] sys_mount+0x8d/0xe0
[<ffffffff81583629>] system_call_fastpath+0x16/0x1b
[<ffffffffffffffff>] 0xffffffffffffffff
I would think this is more likely a bug in the loopback driver than the
FAT filesystem...
------------------------------------------------------------------------
Steven J. Magnani "I claim this network for MARS!
www.digidescorp.com Earthling, return my space modulator!"
#include <standard.disclaimer>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed
2012-07-12 15:16 ` Steven J. Magnani
@ 2012-07-12 19:21 ` OGAWA Hirofumi
2012-07-12 19:39 ` Steven J. Magnani
2012-07-13 15:43 ` Jan Kara
0 siblings, 2 replies; 9+ messages in thread
From: OGAWA Hirofumi @ 2012-07-12 19:21 UTC (permalink / raw)
To: Steven J. Magnani; +Cc: Stevie Trujillo, linux-kernel, Jens Axboe
"Steven J. Magnani" <steve@digidescorp.com> writes:
> On Thu, 2012-07-12 at 16:28 +0200, Stevie Trujillo wrote:
>> Hello,
>>
>> I was trying to create a bootdisk to update my BIOS, and accidentially
>> made a 512byte image with only the FreeDOS header in it.
>>
>> ( Linux 3.4.4 )
>> # mount -o loop dosdisk.img /tmp
>> ^C^C^C
>> It uses 100% CPU and doesn't listen to me when I do ^C, kill -9 etc. I
>> think this means it's stuck in the kernel?
>
> Here is the stack trace I get for the mount process:
>
> [root@telezart smagnani]# cat /proc/1334/stack
> [<ffffffff81077a5a>] __cond_resched+0x2a/0x40
> [<ffffffff8110c4bb>] find_lock_page+0x3b/0x80
> [<ffffffff8110cbaf>] find_or_create_page+0x3f/0xb0
> [<ffffffff8119a692>] __getblk+0xf2/0x2a0
> [<ffffffff8119a893>] __bread+0x13/0xb0
> [<ffffffffa00fd1fe>] fat__get_entry+0x14e/0x220 [fat]
> [<ffffffffa00fd596>] fat_get_short_entry+0x66/0xc0 [fat]
> [<ffffffffa00ff765>] fat_subdirs+0x55/0x80 [fat]
> [<ffffffffa0103d30>] fat_fill_super+0x810/0xa80 [fat]
> [<ffffffffa00e821a>] vfat_fill_super+0x1a/0x20 [vfat]
> [<ffffffff8116d61b>] mount_bdev+0x1cb/0x210
> [<ffffffffa00e81f5>] vfat_mount+0x15/0x20 [vfat]
> [<ffffffff8116e410>] mount_fs+0x20/0xd0
> [<ffffffff81186e4f>] vfs_kern_mount+0x6f/0x100
> [<ffffffff81187804>] do_kern_mount+0x54/0x110
> [<ffffffff811891d6>] do_mount+0x306/0x8b0
> [<ffffffff811898cd>] sys_mount+0x8d/0xe0
> [<ffffffff81583629>] system_call_fastpath+0x16/0x1b
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> I would think this is more likely a bug in the loopback driver than the
> FAT filesystem...
It looks like the bug of __getblk_slow(). If requested block was beyond
end of device, __find_get_block() will find buffer_mapped()'s buffer,
but block >= end_block is unmapped. So, it can be loop.
The following patch fixes it? If it fix, there are some options to check
it.
a) Check it like this patch and warn.
b) (a), but without warn.
c) Check it in init_page_buffers() and return -EIO or such
Well, anyway, Cc to Jens.
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
---
fs/buffer.c | 7 +++++++
1 file changed, 7 insertions(+)
diff -puN fs/buffer.c~debug fs/buffer.c
--- tux3fs/fs/buffer.c~debug 2012-07-13 04:10:40.000000000 +0900
+++ tux3fs-hirofumi/fs/buffer.c 2012-07-13 04:11:50.000000000 +0900
@@ -1055,6 +1055,13 @@ __getblk_slow(struct block_device *bdev,
dump_stack();
return NULL;
}
+ if (block >= blkdev_max_block(I_BDEV(bdev->bd_inode))) {
+ printk(KERN_ERR "getblk(): block %llu, end_block %llu\n",
+ (unsigned long long)block,
+ (unsigned long long)blkdev_max_block(I_BDEV(bdev->bd_inode)));
+ dump_stack();
+ return NULL;
+ }
for (;;) {
struct buffer_head * bh;
_
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed
2012-07-12 19:21 ` OGAWA Hirofumi
@ 2012-07-12 19:39 ` Steven J. Magnani
2012-07-12 19:49 ` OGAWA Hirofumi
2012-07-13 15:43 ` Jan Kara
1 sibling, 1 reply; 9+ messages in thread
From: Steven J. Magnani @ 2012-07-12 19:39 UTC (permalink / raw)
To: OGAWA Hirofumi; +Cc: Stevie Trujillo, linux-kernel, Jens Axboe
On Fri, 2012-07-13 at 04:21 +0900, OGAWA Hirofumi wrote:
> > On Thu, 2012-07-12 at 16:28 +0200, Stevie Trujillo wrote:
> >> Hello,
> >>
> >> I was trying to create a bootdisk to update my BIOS, and accidentially
> >> made a 512byte image with only the FreeDOS header in it.
> >>
> >> ( Linux 3.4.4 )
> >> # mount -o loop dosdisk.img /tmp
> >> ^C^C^C
> >> It uses 100% CPU and doesn't listen to me when I do ^C, kill -9 etc. I
> >> think this means it's stuck in the kernel?
> It looks like the bug of __getblk_slow(). If requested block was beyond
> end of device, __find_get_block() will find buffer_mapped()'s buffer,
> but block >= end_block is unmapped. So, it can be loop.
>
> The following patch fixes it? If it fix, there are some options to check
> it.
>
> a) Check it like this patch and warn.
> b) (a), but without warn.
> c) Check it in init_page_buffers() and return -EIO or such
>
> Well, anyway, Cc to Jens.
>
> Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
> ---
>
> fs/buffer.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff -puN fs/buffer.c~debug fs/buffer.c
> --- tux3fs/fs/buffer.c~debug 2012-07-13 04:10:40.000000000 +0900
> +++ tux3fs-hirofumi/fs/buffer.c 2012-07-13 04:11:50.000000000 +0900
> @@ -1055,6 +1055,13 @@ __getblk_slow(struct block_device *bdev,
> dump_stack();
> return NULL;
> }
> + if (block >= blkdev_max_block(I_BDEV(bdev->bd_inode))) {
> + printk(KERN_ERR "getblk(): block %llu, end_block %llu\n",
> + (unsigned long long)block,
> + (unsigned long long)blkdev_max_block(I_BDEV(bdev->bd_inode)));
> + dump_stack();
> + return NULL;
> + }
>
> for (;;) {
> struct buffer_head * bh;
> _
This fixes the hang, but I'm not sure dump_stack() is a good idea. I get
almost 100 lines of stack dumps and error messages in my kernel log.
Also, I was a little surprised to see that mount completes successfully.
------------------------------------------------------------------------
Steven J. Magnani "I claim this network for MARS!
www.digidescorp.com Earthling, return my space modulator!"
#include <standard.disclaimer>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed
2012-07-12 19:39 ` Steven J. Magnani
@ 2012-07-12 19:49 ` OGAWA Hirofumi
0 siblings, 0 replies; 9+ messages in thread
From: OGAWA Hirofumi @ 2012-07-12 19:49 UTC (permalink / raw)
To: Steven J. Magnani; +Cc: Stevie Trujillo, linux-kernel, Jens Axboe
"Steven J. Magnani" <steve@digidescorp.com> writes:
>> The following patch fixes it? If it fix, there are some options to check
>> it.
>>
>> a) Check it like this patch and warn.
>> b) (a), but without warn.
>> c) Check it in init_page_buffers() and return -EIO or such
>>
>> Well, anyway, Cc to Jens.
>>
>> Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
>> ---
>>
>> fs/buffer.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff -puN fs/buffer.c~debug fs/buffer.c
>> --- tux3fs/fs/buffer.c~debug 2012-07-13 04:10:40.000000000 +0900
>> +++ tux3fs-hirofumi/fs/buffer.c 2012-07-13 04:11:50.000000000 +0900
>> @@ -1055,6 +1055,13 @@ __getblk_slow(struct block_device *bdev,
>> dump_stack();
>> return NULL;
>> }
>> + if (block >= blkdev_max_block(I_BDEV(bdev->bd_inode))) {
>> + printk(KERN_ERR "getblk(): block %llu, end_block %llu\n",
>> + (unsigned long long)block,
>> + (unsigned long long)blkdev_max_block(I_BDEV(bdev->bd_inode)));
>> + dump_stack();
>> + return NULL;
>> + }
>>
>> for (;;) {
>> struct buffer_head * bh;
>> _
>
> This fixes the hang, but I'm not sure dump_stack() is a good idea. I get
> almost 100 lines of stack dumps and error messages in my kernel log.
> Also, I was a little surprised to see that mount completes successfully.
So, it sounds like the good choice would be (b) or (c). Well, I guess
Jens would choose what to do.
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed
2012-07-12 19:21 ` OGAWA Hirofumi
2012-07-12 19:39 ` Steven J. Magnani
@ 2012-07-13 15:43 ` Jan Kara
2012-07-13 15:52 ` Jeff Moyer
2012-07-13 20:51 ` Jeff Moyer
1 sibling, 2 replies; 9+ messages in thread
From: Jan Kara @ 2012-07-13 15:43 UTC (permalink / raw)
To: OGAWA Hirofumi
Cc: Steven J. Magnani, Stevie Trujillo, linux-kernel, Jens Axboe, Jeff Moyer
On Fri 13-07-12 04:21:44, OGAWA Hirofumi wrote:
> "Steven J. Magnani" <steve@digidescorp.com> writes:
>
> > On Thu, 2012-07-12 at 16:28 +0200, Stevie Trujillo wrote:
> >> Hello,
> >>
> >> I was trying to create a bootdisk to update my BIOS, and accidentially
> >> made a 512byte image with only the FreeDOS header in it.
> >>
> >> ( Linux 3.4.4 )
> >> # mount -o loop dosdisk.img /tmp
> >> ^C^C^C
> >> It uses 100% CPU and doesn't listen to me when I do ^C, kill -9 etc. I
> >> think this means it's stuck in the kernel?
> >
> > Here is the stack trace I get for the mount process:
> >
> > [root@telezart smagnani]# cat /proc/1334/stack
> > [<ffffffff81077a5a>] __cond_resched+0x2a/0x40
> > [<ffffffff8110c4bb>] find_lock_page+0x3b/0x80
> > [<ffffffff8110cbaf>] find_or_create_page+0x3f/0xb0
> > [<ffffffff8119a692>] __getblk+0xf2/0x2a0
> > [<ffffffff8119a893>] __bread+0x13/0xb0
> > [<ffffffffa00fd1fe>] fat__get_entry+0x14e/0x220 [fat]
> > [<ffffffffa00fd596>] fat_get_short_entry+0x66/0xc0 [fat]
> > [<ffffffffa00ff765>] fat_subdirs+0x55/0x80 [fat]
> > [<ffffffffa0103d30>] fat_fill_super+0x810/0xa80 [fat]
> > [<ffffffffa00e821a>] vfat_fill_super+0x1a/0x20 [vfat]
> > [<ffffffff8116d61b>] mount_bdev+0x1cb/0x210
> > [<ffffffffa00e81f5>] vfat_mount+0x15/0x20 [vfat]
> > [<ffffffff8116e410>] mount_fs+0x20/0xd0
> > [<ffffffff81186e4f>] vfs_kern_mount+0x6f/0x100
> > [<ffffffff81187804>] do_kern_mount+0x54/0x110
> > [<ffffffff811891d6>] do_mount+0x306/0x8b0
> > [<ffffffff811898cd>] sys_mount+0x8d/0xe0
> > [<ffffffff81583629>] system_call_fastpath+0x16/0x1b
> > [<ffffffffffffffff>] 0xffffffffffffffff
> >
> > I would think this is more likely a bug in the loopback driver than the
> > FAT filesystem...
>
> It looks like the bug of __getblk_slow(). If requested block was beyond
> end of device, __find_get_block() will find buffer_mapped()'s buffer,
> but block >= end_block is unmapped. So, it can be loop.
>
> The following patch fixes it? If it fix, there are some options to check
> it.
>
> a) Check it like this patch and warn.
> b) (a), but without warn.
> c) Check it in init_page_buffers() and return -EIO or such
>
> Well, anyway, Cc to Jens.
>
> Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
I think Jeff Moyer has sent a similar fix recently. It may even be
already queued in Jens' tree. Jeff?
Honza
> ---
>
> fs/buffer.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff -puN fs/buffer.c~debug fs/buffer.c
> --- tux3fs/fs/buffer.c~debug 2012-07-13 04:10:40.000000000 +0900
> +++ tux3fs-hirofumi/fs/buffer.c 2012-07-13 04:11:50.000000000 +0900
> @@ -1055,6 +1055,13 @@ __getblk_slow(struct block_device *bdev,
> dump_stack();
> return NULL;
> }
> + if (block >= blkdev_max_block(I_BDEV(bdev->bd_inode))) {
> + printk(KERN_ERR "getblk(): block %llu, end_block %llu\n",
> + (unsigned long long)block,
> + (unsigned long long)blkdev_max_block(I_BDEV(bdev->bd_inode)));
> + dump_stack();
> + return NULL;
> + }
>
> for (;;) {
> struct buffer_head * bh;
> _
>
> --
> OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed
2012-07-13 15:43 ` Jan Kara
@ 2012-07-13 15:52 ` Jeff Moyer
2012-07-13 20:51 ` Jeff Moyer
1 sibling, 0 replies; 9+ messages in thread
From: Jeff Moyer @ 2012-07-13 15:52 UTC (permalink / raw)
To: Jan Kara
Cc: OGAWA Hirofumi, Steven J. Magnani, Stevie Trujillo, linux-kernel,
Jens Axboe
Jan Kara <jack@suse.cz> writes:
>> It looks like the bug of __getblk_slow(). If requested block was beyond
>> end of device, __find_get_block() will find buffer_mapped()'s buffer,
>> but block >= end_block is unmapped. So, it can be loop.
>>
>> The following patch fixes it? If it fix, there are some options to check
>> it.
>>
>> a) Check it like this patch and warn.
>> b) (a), but without warn.
>> c) Check it in init_page_buffers() and return -EIO or such
>>
>> Well, anyway, Cc to Jens.
>>
>> Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
> I think Jeff Moyer has sent a similar fix recently. It may even be
> already queued in Jens' tree. Jeff?
I haven't heard a peep from Jens (I believe he's been on vacation), so I
forwarded the patch along to Linus (but haven't heard anything from him,
either).
See my email with Subject: [patch] block: fix infinite loop in __getblk_slow
https://lkml.org/lkml/2012/6/26/252
Cheers,
Jeff
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed
2012-07-13 15:43 ` Jan Kara
2012-07-13 15:52 ` Jeff Moyer
@ 2012-07-13 20:51 ` Jeff Moyer
1 sibling, 0 replies; 9+ messages in thread
From: Jeff Moyer @ 2012-07-13 20:51 UTC (permalink / raw)
To: Jan Kara
Cc: OGAWA Hirofumi, Steven J. Magnani, Stevie Trujillo, linux-kernel,
Jens Axboe
Jan Kara <jack@suse.cz> writes:
>> It looks like the bug of __getblk_slow(). If requested block was beyond
>> end of device, __find_get_block() will find buffer_mapped()'s buffer,
>> but block >= end_block is unmapped. So, it can be loop.
>>
>> The following patch fixes it? If it fix, there are some options to check
>> it.
>>
>> a) Check it like this patch and warn.
>> b) (a), but without warn.
>> c) Check it in init_page_buffers() and return -EIO or such
>>
>> Well, anyway, Cc to Jens.
>>
>> Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
> I think Jeff Moyer has sent a similar fix recently. It may even be
> already queued in Jens' tree. Jeff?
A fix for this has now been committed in Linus' tree:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=91f68c89d8f35fe98ea04159b9a3b42d0149478f
Cheers,
Jeff
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed
@ 2012-07-13 9:18 Wolfram Gloger
0 siblings, 0 replies; 9+ messages in thread
From: Wolfram Gloger @ 2012-07-13 9:18 UTC (permalink / raw)
To: linux-kernel
Hi,
Maybe the patch referenced in
http://lkml.indiana.edu/hypermail/linux/kernel/1206.2/02163.html
also relevant in -stable as noted in
http://lkml.indiana.edu/hypermail/linux/kernel/1206.2/02717.html
is also relevant here?
Regards,
Wolfram.
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-07-13 20:52 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-12 14:28 mount -o loop with truncated dosdisk.img uses 100% cpu and can't be killed Stevie Trujillo
2012-07-12 15:16 ` Steven J. Magnani
2012-07-12 19:21 ` OGAWA Hirofumi
2012-07-12 19:39 ` Steven J. Magnani
2012-07-12 19:49 ` OGAWA Hirofumi
2012-07-13 15:43 ` Jan Kara
2012-07-13 15:52 ` Jeff Moyer
2012-07-13 20:51 ` Jeff Moyer
2012-07-13 9:18 Wolfram Gloger
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.