woodyng1985 | 5 Mar 11:09 2012
Picon

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

Ryusuke Konishi | 5 Mar 15:30 2012
Picon

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)

Ryusuke Konishi | 5 Mar 16:33 2012
Picon

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)

Jan Kara | 5 Mar 17:00 2012
Picon

[PATCH 00/19] Fix filesystem freezing deadlocks

  Hallelujah,

  after a couple of weeks and several rewrites, here comes the third iteration
of my patches to improve filesystem freezing.  Filesystem freezing is currently
racy and thus we can end up with dirty data on frozen filesystem (see changelog
patch 06 for detailed race description). This patch series aims at fixing this.

To be able to block all places where inodes get dirtied, I've moved filesystem
freeze handling in mnt_want_write() / mnt_drop_write(). This however required
some code shuffling and changes to kern_path_create() (see patches 02-05). I
think the result is OK but opinions may differ ;). The advantage of this change
also is that all filesystems get freeze protection almost for free - even ext2
can handle freezing well now.

Another potential contention point might be patch 19. In that patch we make
freeze_super() refuse to freeze the filesystem when there are open but unlinked
files which may be impractical in some cases. The main reason for this is the
problem with handling of file deletion from fput() called with mmap_sem held
(e.g. from munmap(2)), and then there's the fact that we cannot really force
such filesystem into a consistent state... But if people think that freezing
with open but unlinked files should happen, then I have some possible
solutions in mind (maybe as a separate patchset since this is large enough).

I'm not able to hit any deadlocks, lockdep warnings, or dirty data on frozen
filesystem despite beating it with fsstress and bash-shared-mapping while
freezing and unfreezing for several hours (using ext4 and xfs) so I'm
reasonably confident this could finally be the right solution.

And for people wanting to test - this patchset is based on patch series
"Push file_update_time() into .page_mkwrite" so you'll need to pull that one
(Continue reading)

Jan Kara | 5 Mar 17:01 2012
Picon

[PATCH 16/19] nilfs2: Convert to new freezing mechanism

We change nilfs_page_mkwrite() to provide proper freeze protection for
writeable page faults (we must wait for frozen filesystem even if the
page is fully mapped).

We remove all vfs_check_frozen() checks since they are now handled by
the generic code.

CC: linux-nilfs <at> vger.kernel.org
CC: KONISHI Ryusuke <konishi.ryusuke <at> lab.ntt.co.jp>
Signed-off-by: Jan Kara <jack <at> suse.cz>
---
 fs/nilfs2/file.c    |   18 +++++++++++-------
 fs/nilfs2/ioctl.c   |    2 --
 fs/nilfs2/segment.c |    2 --
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/fs/nilfs2/file.c b/fs/nilfs2/file.c
index 2660152..0cdd702 100644
--- a/fs/nilfs2/file.c
+++ b/fs/nilfs2/file.c
 <at>  <at>  -65,16 +65,18  <at>  <at>  static int nilfs_page_mkwrite(struct vm_area_struct *vma, struct vm_fault *vmf)
 	struct page *page = vmf->page;
 	struct inode *inode = vma->vm_file->f_dentry->d_inode;
 	struct nilfs_transaction_info ti;
-	int ret;
+	int ret = 0;

 	if (unlikely(nilfs_near_disk_full(inode->i_sb->s_fs_info)))
 		return VM_FAULT_SIGBUS; /* -ENOSPC */

(Continue reading)

Slicky Devil | 6 Mar 14:24 2012
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)

Ryusuke Konishi | 6 Mar 15:54 2012
Picon

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)

Slicky Devil | 6 Mar 22:07 2012
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)

Kenneth Langga | 7 Mar 07:13 2012
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

Gordan Bobic | 7 Mar 10:31 2012
Picon

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


Gmane