sfjro | 4 May 2009 01:50
Picon

aufs2 Monday GIT release


The aufs2 GIT trees on http://git.c3sl.ufpr.br/pub/scm are updated.
If I made something wrong about tree management, please let me know.

News
- first draft of 'rum-work' branch for Readonly Union Mount.

J. R. Okajima

----------------------------------------------------------------------

- aufs2-2.6.git:aufs2 branch
- aufs2-standalone.git:aufs2 branch
      aufs: remove temporary workaround for a bug in NFSD readdir

------------------------------------------------------------------------------
Register Now & Save for Velocity, the Web Performance & Operations 
Conference from O'Reilly Media. Velocity features a full day of 
expert-led, hands-on workshops and two days of sessions from industry 
leaders in dedicated Performance & Operations tracks. Use code vel09scf 
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf

sfjro | 5 May 2009 08:08
Picon

ecryptfs.patch in aufs2-standalone.git


Hi all,

Anyone who want ecryptfs.patch in aufs2-standalone.git?

Ecryptfs has some problems, some are generic and others may be specific
when it is used as an aufs branch (See
<http://marc.info/?l=linux-kernel&m=123182836524506&w=2> and its thread
in detail).
I developed the ecryptfs.patch when I knew an aufs user had a plan to
use ecryptfs as an aufs branch. But recently I recognized he/they
stopped using aufs. So the patch may be used by nobody.

If someone else will not stop me, I will remove the patch in next Monday
release.

J. R. Okajima

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com

sfjro | 10 May 2009 23:49
Picon

aufs2 Monday GIT release


The aufs2 GIT trees on http://git.c3sl.ufpr.br/pub/scm are updated.
If I made something wrong about tree management, please let me know.

News
- optimize vdir
- ectyptfs.patch (for linux-2.6.30 only) was removed from
  aufs2-standalone.git:aufs2 branch

J. R. Okajima

----------------------------------------------------------------------
- aufs2-2.6.git, aufs2-standalone.git
      aufs: tiny: simplified vdir
      aufs: tiny: rename namelen to nlen
      aufs: make au_nhash single layerd
      aufs: optimize vdir
      aufs: update donors
      aufs: vdir, minor optimization
      aufs: tiny, revert full copyright sentences
      aufs: update a donor

- aufs2-standalone.git:aufs2 branch
  Addition to above,
      remove ecryptfs.patch

- aufs2-util.git:master branch
  None

------------------------------------------------------------------------------
(Continue reading)

Joonwoo Park | 13 May 2009 00:19
Picon

Fwd: aufs2 with ubifs mmap problem

I'm rejected to post on the list so I'm resending.
Hope it works this time.

Thanks,
Joonwoo

---------- Forwarded message ----------
From: Joonwoo Park <joonwpark81 <at> gmail.com>
To: "J. R. Okajima" <hooanon05 <at> yahoo.co.jp>
Date: Tue, 12 May 2009 14:29:49 -0700
Subject: aufs2 with ubifs mmap problem
Hello,

I've encounter a aufs related problem when I use mmap on ubifs as
read-write branch.
FYI, I cannot see this problem on ubifs only partition, aufs with
tmpfs branch and aufs with ext3 branch.

The problem that I encountered was ubifs set_page_dirty() assertion
failure when mmap-ing to aufs filesystem which has branch as ubifs
filesystem.
I had a quick aufs hacking and I've inclined that aufs should have
handled page_mkwrite of vm_operation.  The current version of aufs2 is
registering only aufs_fault.
Please find attached patch file aufs-mmap-fault.patch and correct me
if I'm wrong.

Attached patch looked like solve this problem but no luck.
This patch reduced lots of ubifs assertion failures but I'm still
seeing assertion failure after large size of mmap writing (actually
(Continue reading)

sfjro | 13 May 2009 05:06
Picon

Re: Fwd: aufs2 with ubifs mmap problem


Hello Joonwoo,

Joonwoo Park:
> The problem that I encountered was ubifs set_page_dirty() assertion
> failure when mmap-ing to aufs filesystem which has branch as ubifs
> filesystem.
> I had a quick aufs hacking and I've inclined that aufs should have
> handled page_mkwrite of vm_operation. =A0The current version of aufs2 is
> registering only aufs_fault.
> Please find attached patch file aufs-mmap-fault.patch and correct me
> if I'm wrong.

I will read ubifs and try your test program, but it will take some time.
Just to make sure, your kernel is plain linux-2.6.27, isn't it?
And where can I get ubiattach and ubimkvol tools?

While I am not sure this is related to your problem, but mwr.c needs
fixing.

    /* Now write int's to the file as if it were memory (an array of ints).
     */
    for (i = 1; i <=NUMINTS; ++i) {
	map[i] = 2 * i; 
    }

'i' must be less than NUMINTS.
I guess you want to do,
    for (i = 0; i < NUMINTS; ...

(Continue reading)

Joonwoo Park | 13 May 2009 05:32
Picon

Re: Fwd: aufs2 with ubifs mmap problem

Hello J. R.

On Tue, May 12, 2009 at 8:06 PM,  <sfjro <at> users.sourceforge.net> wrote:
>
> Hello Joonwoo,
>
> Joonwoo Park:
>> The problem that I encountered was ubifs set_page_dirty() assertion
>> failure when mmap-ing to aufs filesystem which has branch as ubifs
>> filesystem.
>> I had a quick aufs hacking and I've inclined that aufs should have
>> handled page_mkwrite of vm_operation. =A0The current version of aufs2 is
>> registering only aufs_fault.
>> Please find attached patch file aufs-mmap-fault.patch and correct me
>> if I'm wrong.
>
> I will read ubifs and try your test program, but it will take some time.
> Just to make sure, your kernel is plain linux-2.6.27, isn't it?

Yes, actually I'm using 2.6.27.8 but there was same problem on 2.6.29.x

> And where can I get ubiattach and ubimkvol tools?

You could install mtd-utils package with your system's package software.
Otherwise please try clone git://git.infradead.org/mtd-utils.git directly.

>
> While I am not sure this is related to your problem, but mwr.c needs
> fixing.

(Continue reading)

sfjro | 13 May 2009 11:20
Picon

Re: Fwd: aufs2 with ubifs mmap problem

Joonwoo Park:
> Attached patch looked like solve this problem but no luck.
> This patch reduced lots of ubifs assertion failures but I'm still
> seeing assertion failure after large size of mmap writing (actually
> exiting the process after mmap writing).
> It seems that I still have a problem when do_munmap from sys_exit is called=
> .
> 
> Do you have any idea for this issue?

Addition to your patch, please test this patch too.
I am testing now.

> I can reproduce this problem without real nand flash chip like below,
> You have to configure CONFIG_UBIFS_FS_DEBUG to get ubifs assertion:
> modprobe ubifs
> modprobe nandsim
> ubiattach /dev/ubi_ctrl -m 0
> ubimkvol /dev/ubi1 -m -N commonrw
> mount -t ubifs -o rw,sync ubi1:commonrw /tmp/rw

I had to change a little these commands.
Is this OK?

ubiattach /dev/ubi_ctrl -m 0
ubimkvol /dev/ubi0 -s 32MiB -N commonrw
mount -t ubifs -o rw,sync ubi:commonrw /tmp/rw
	:::
umount /tmp/rw
ubirmvol /dev/ubi0 -n 0
(Continue reading)

Joonwoo Park | 13 May 2009 17:41
Picon

Re: Fwd: aufs2 with ubifs mmap problem

J. R.

On Wed, May 13, 2009 at 2:20 AM,  <sfjro <at> users.sourceforge.net> wrote:
> Joonwoo Park:
>> Attached patch looked like solve this problem but no luck.
>> This patch reduced lots of ubifs assertion failures but I'm still
>> seeing assertion failure after large size of mmap writing (actually
>> exiting the process after mmap writing).
>> It seems that I still have a problem when do_munmap from sys_exit is called=
>> .
>>
>> Do you have any idea for this issue?
>
> Addition to your patch, please test this patch too.
> I am testing now.
>

Awesome.  it's working smoothly.
Could you please consider to apply these patches?
It will be great.  I'll sign off my patch if you want.
Thanks a lot.

>
>> I can reproduce this problem without real nand flash chip like below,
>> You have to configure CONFIG_UBIFS_FS_DEBUG to get ubifs assertion:
>> modprobe ubifs
>> modprobe nandsim
>> ubiattach /dev/ubi_ctrl -m 0
>> ubimkvol /dev/ubi1 -m -N commonrw
>> mount -t ubifs -o rw,sync ubi1:commonrw /tmp/rw
(Continue reading)

sfjro | 13 May 2009 18:39
Picon

Re: Fwd: aufs2 with ubifs mmap problem


Joonwoo Park:
> Awesome.  it's working smoothly.
> Could you please consider to apply these patches?
> It will be great.  I'll sign off my patch if you want.
> Thanks a lot.

Glad to hear that!
But I might found a problem in ubifs and I posted a question to the
author and linux-fsdevel ML.

Anyway I will include your patch (and mine) in next Monday release.

Thank you
J. R. Okajima

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com

Joonwoo Park | 13 May 2009 18:55
Picon

Re: Fwd: aufs2 with ubifs mmap problem

On Wed, May 13, 2009 at 9:39 AM,  <sfjro <at> users.sourceforge.net> wrote:
>
> Joonwoo Park:
>> Awesome.  it's working smoothly.
>> Could you please consider to apply these patches?
>> It will be great.  I'll sign off my patch if you want.
>> Thanks a lot.
>
> Glad to hear that!
> But I might found a problem in ubifs and I posted a question to the
> author and linux-fsdevel ML.

Interesting.  I'm also suspecting another inode locking problem of
ubifs when it's used with aufs.
I'll let list know if I convinced.

>
> Anyway I will include your patch (and mine) in next Monday release.
>

Thanks!
Joonwoo

> Thank you
> J. R. Okajima
>

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
(Continue reading)


Gmane