headers
@@@ | 5 Mar 2012 11:09
Picon
Favicon

Hong Kong Cloud System

Dear All,

We are one of the top Cloud Solution provider base in Hong Kong, with over 10+ years experience,
we providing better than good and lower cost service of CLoud Hosting (Cloud Server / Hosting / CDN)

Starting at $1.99, let's come to experience and enjoy our powerful cloud system.

Thanks for your time and appreciated to look arround our website.

http://www.dedicatedserver.com.hk/ 

Best Regards,
The 36cloud Team

If you do not wish to further receive this event message, email
"subscriber@..." to unsubscribe this message or
revoe your email from the list.

--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Ryusuke Konishi | 5 Mar 2012 15:30
Picon
Gravatar

Re: BUG: unable to handle kernel NULL pointer dereference at 00000048

Hi,
On Wed, 29 Feb 2012 17:31:18 +0300, Slicky Devil wrote:
> Hello!
> 
> I think I found a bug for you, guys.
> 
> The situation was as following. At first, I set up LVM with a single
> lv (with nilfs) for root. Everything worked fine. Then I decided to
> create a separate home partition. I shrank the root a bit, created
> another nilfs logical volume for home. Then I shrank root/expanded
> home a couple of times. In the end I got the bug, when tried to mount
> the home.
> 
> I'm pretty much confident (say 90%) that I didn't mess things up by
> shrinking a partition before resizing the appropriate filesystem.
>
> Now every time I try to mount home I get the following:
> 
> [ 1367.830334] BUG: unable to handle kernel NULL pointer dereference at 00000048
> [ 1367.831581] IP: [<d0d7a08e>] nilfs_load_super_block+0x17e/0x280 [nilfs2]
> [ 1367.832098] *pde = 00000000
> [ 1367.832596] Oops: 0000 [#1] PREEMPT SMP
> [ 1367.833098] Modules linked in: ext2 mbcache snd_intel8x0 e1000
> ppdev snd_ac97_codec ac97_bus snd_pcm snd_page_alloc vboxvideo(O)
> snd_timer drm snd agpgart parport_pc soundcore parport i2c_piix4
> i2c_core serio_raw psmouse pcspkr evdev joydev processor ac button
> vboxsf(O) vboxguest(O) nilfs2 dm_mod sr_mod cdrom sd_mod usbhid hid
> ahci libahci libata ohci_hcd scsi_mod usbcore usb_common
> [ 1367.833562]
> [ 1367.833562] Pid: 710, comm: mount.nilfs2 Tainted: G           O
(Continue reading)

Permalink | Reply | 5 comments |
headers
Ryusuke Konishi | 5 Mar 2012 16:33
Picon
Gravatar

Re: BUG: unable to handle kernel NULL pointer dereference at 00000048

On Mon, 05 Mar 2012 23:30:28 +0900 (JST), Ryusuke Konishi wrote:
> Hi,
> On Wed, 29 Feb 2012 17:31:18 +0300, Slicky Devil wrote:
> > Hello!
> > 
> > I think I found a bug for you, guys.
> > 
> > The situation was as following. At first, I set up LVM with a single
> > lv (with nilfs) for root. Everything worked fine. Then I decided to
> > create a separate home partition. I shrank the root a bit, created
> > another nilfs logical volume for home. Then I shrank root/expanded
> > home a couple of times. In the end I got the bug, when tried to mount
> > the home.
> > 
> > I'm pretty much confident (say 90%) that I didn't mess things up by
> > shrinking a partition before resizing the appropriate filesystem.
> >
> > Now every time I try to mount home I get the following:
> > 
> > [ 1367.830334] BUG: unable to handle kernel NULL pointer dereference at 00000048
> > [ 1367.831581] IP: [<d0d7a08e>] nilfs_load_super_block+0x17e/0x280 [nilfs2]
> > [ 1367.832098] *pde = 00000000
> > [ 1367.832596] Oops: 0000 [#1] PREEMPT SMP
> > [ 1367.833098] Modules linked in: ext2 mbcache snd_intel8x0 e1000
> > ppdev snd_ac97_codec ac97_bus snd_pcm snd_page_alloc vboxvideo(O)
> > snd_timer drm snd agpgart parport_pc soundcore parport i2c_piix4
> > i2c_core serio_raw psmouse pcspkr evdev joydev processor ac button
> > vboxsf(O) vboxguest(O) nilfs2 dm_mod sr_mod cdrom sd_mod usbhid hid
> > ahci libahci libata ohci_hcd scsi_mod usbcore usb_common
> > [ 1367.833562]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Slicky Devil | 6 Mar 2012 14:24
Picon

Re: BUG: unable to handle kernel NULL pointer dereference at 00000048

Luckily, I seem to have been able to reproduce the bug (after
shrinking the partition down to some hundred MB). Your patch seems to
have fixed it!

Now I get the following, which, I think, is pretty much expected,
since I chopped a large part of the filesystem off:

15:52 root ~ # mount /dev/1/buggy-home test
[  461.137823] NILFS: error searching super root.
mount.nilfs2: Error while mounting /dev/mapper/1-buggy--home on
/root/test: Input/output error

Please, fix the bug in the official kernel sources, too. Your
filesystem proved very useful here for storing documents and other
changeable stuff -- we don't want it get broken unexpectedly. :)

Still, thanks a lot! The things you are doing here are really cool!

Cheers!

On Mon, Mar 5, 2012 at 5:30 PM, Ryusuke Konishi
<konishi.ryusuke@...> wrote:
>
> Thank you for reporting this issue.
>
> I found a bug in the nilfs_load_super_block function which has
> potential to cause this oops.
>
> Could you try the following patch if you still have the partition ?
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ryusuke Konishi | 6 Mar 2012 15:54
Picon
Gravatar

Re: BUG: unable to handle kernel NULL pointer dereference at 00000048

Hi,
On Tue, 6 Mar 2012 16:24:40 +0300, Slicky Devil wrote:
> Luckily, I seem to have been able to reproduce the bug (after
> shrinking the partition down to some hundred MB). Your patch seems to
> have fixed it!
> 
> Now I get the following, which, I think, is pretty much expected,
> since I chopped a large part of the filesystem off:
> 
> 15:52 root ~ # mount /dev/1/buggy-home test
> [  461.137823] NILFS: error searching super root.
> mount.nilfs2: Error while mounting /dev/mapper/1-buggy--home on
> /root/test: Input/output error

Hmmm.  Did you shrink the filesystem with nilfs-resize tool
before shrinking the partition ?

This error (I/O error) also looks undesirable to me.

 
> Please, fix the bug in the official kernel sources, too. Your
> filesystem proved very useful here for storing documents and other
> changeable stuff -- we don't want it get broken unexpectedly. :)

Sure, I will send the fix upstream (and stable trees).

Thanks,
Ryusuke Konishi

> Still, thanks a lot! The things you are doing here are really cool!
(Continue reading)

Permalink | Reply | 2 comments |
headers
Slicky Devil | 6 Mar 2012 22:07
Picon

Re: BUG: unable to handle kernel NULL pointer dereference at 00000048

On Tue, Mar 6, 2012 at 5:54 PM, Ryusuke Konishi
<konishi.ryusuke@...> wrote:
> Hmmm.  Did you shrink the filesystem with nilfs-resize tool
> before shrinking the partition ?
>
> This error (I/O error) also looks undesirable to me.

I couldn't shrink the filesystem, because I couldn't mount it because
of the bug. The filesystem was large and I was in desparate need of
some spare diskspace. At first, I was going to completely get rid of
it, but then I thought you might want to have a look at the
superblock, or some othe block, or whatever else to analyze the bug.
Since the bug was some sort of initialization issue, I finally decided
to keep the first 500 MB of the filesystem and reclaimed the rest of
it (by shrinking the partition).

And all that had happened *before* I posted the bug report on this mailing list.

Luckily, when I tried to mount the "broken" filesystem today, the
nilfs driver exposed the very same oops again. I applied your
patch/recompiled the kernel and the oops disappeared.

So, no. I didn't use any nilfs-resize. And those IO error are pretty
much expected to me.
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kenneth Langga | 7 Mar 2012 07:13
Picon

Questions on nilfs_cleanerd

1) Does the daemon read/write the entire drive to look for dead blocks to clean?

2) What if there aren't any dead blocks to clean and the free space in
the drive is still less than 10% (the default min_clean_segments in
the conf file), does the daemon still process the drive? If so, how do
I change the cleaning interval so that it doesn't process the drive as
often?
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 1 comment |
headers
Gordan Bobic | 7 Mar 2012 10:31
Gravatar

Re: Questions on nilfs_cleanerd

These sound similar to the questions/concerns I raised a while back.

> 1) Does the daemon read/write the entire drive to look for dead blocks to clean?

Yes - sequentially (and then it rolls over to the beginning again).

> 2) What if there aren't any dead blocks to clean and the free space in
> the drive is still less than 10% (the default min_clean_segments in
> the conf file), does the daemon still process the drive? If so, how do
> I change the cleaning interval so that it doesn't process the drive as
> often?

The only worthwhile suggestion I heard is to set the minimum history 
retention rate (the FS is continuously snapshotting) to 1 day. That way 
you can guarantee the churn rate will never exceed the capacity of the 
disk per day. Not ideal, but at least it puts some kind of a hard limit 
on how quickly it'll waste your flash - at the expense of making the 
problem of the non-determinism of free space a little worse.

Gordan
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane