aufs2 Monday GIT release

o news
  No news is good news.

J. R. Okajima
If you or your company use and like AUFS project,  why not consider
donating money, or getting a service contract with the developer to
ensure that it will live on and continue to provide high quality free
software?

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

- aufs2-2.6.git
      aufs: cosmetic clean-up for i_op_del.c
      aufs: cosmetic clean-up for i_op_ren.c
      aufs: cosmetic clean-up for sysfs.c
      aufs: cosmetic clean-up for hinotify.c
      aufs: cosmetic clean-up for export.c
      aufs: cosmetic clean-up for rdu.c
      Revert "aufs: cosmetic clean-up for export.c"

- aufs2-standalone.git
  ditto

- aufs2-util.git
  None

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs

Re: Problem with aufs on top of tmpfs: memory going missing...

Rene Mayrhofer:
> Yes, we are still using aufs2 and still have this problem.
>
> > This small patch MAY be able to reduce the size of XINO file for the
> > upper tmpfs branch.
> > If you can, would you test this patch?
> > It is not a part of aufs, but modifies tmpfs. So you will need to
> > re-compile the kernel.
>
> We will try it - thanks for the patch!

Rene, I forgot one important thing.
This problem was known and I had already implmented the solution.
Please read the thread in Nov 2007.
http://sourceforge.net/mailarchive/forum.php?thread_name=20071126230908.GB5945%40falooley.org&forum_name=aufs-users

(You may want to see another archive on another user site since the
archive on SF is slow and not easy to follow the thread)

Jason Lunz wrote the problem which is very similar to yours.
And I impelmented some options to truncate the XINO files.

(from the mail on 2007-11-29)
----------------------------------------------------------------------
     Here is patch for it, which introduces two new re-mount options,
     - trunc_xino=<branch path>
     - itrunc_xino=<branch index>
     ex. sudo mount -o remount,itrunc_xino=0 /your/aufs

ubifs doesn't maintain i_blocks.

Hi,

According to comment of au_test_fs_bad_iattr_size() it should return 1
if filesystem doesn't maintain i_blocks.
It seems to me ubifs doesn't maintain i_blocks like xfs.
Please find attached patch and review it.

Thanks,
Joonwoo

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

Re: ubifs doesn't maintain i_blocks.

Hello Joonwoo,

Joonwoo Park:
> According to comment of au_test_fs_bad_iattr_size() it should return 1
> if filesystem doesn't maintain i_blocks.
> It seems to me ubifs doesn't maintain i_blocks like xfs.
> Please find attached patch and review it.

Thank you very much for the patch.
Because I don't use ubifs, the ubifs line in au_test_fs_bad_iattr_size()
was commented out as 'untested.'
Are you using aufs with ubifs? And does it work well?
If so, I'd like to remove the 'untested' comment as well as uncomment
the ubifs line.

J. R. Okajima

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

Re: ubifs doesn't maintain i_blocks.

Hello J. R.

Yes I'm using aufs with ubifs.
It looks work fine with me but my problem is I'm not 100% sure everything works.
I'm not good at file system stuffs.

So about this change can you suggest me any test cases?
Until now I'm running bonnie++ and an application to test mmap functionality.

Thanks,
Joonwoo

On Mon, Mar 1, 2010 at 8:17 PM,  <sfjro <at> users.sourceforge.net> wrote:
>
> Hello Joonwoo,
>
> Joonwoo Park:
>> According to comment of au_test_fs_bad_iattr_size() it should return 1
>> if filesystem doesn't maintain i_blocks.
>> It seems to me ubifs doesn't maintain i_blocks like xfs.
>> Please find attached patch and review it.
>
> Thank you very much for the patch.
> Because I don't use ubifs, the ubifs line in au_test_fs_bad_iattr_size()
> was commented out as 'untested.'
> Are you using aufs with ubifs? And does it work well?
> If so, I'd like to remove the 'untested' comment as well as uncomment
> the ubifs line.
>
>

Re: ubifs doesn't maintain i_blocks.

Joonwoo Park:
> So about this change can you suggest me any test cases?
> Until now I'm running bonnie++ and an application to test mmap functionality.

The main purpose of the tests will be
- stat(2) familly in aufs should return the same value to the one in
  ubifs.
- aufs should not create the XINO files on ubifs.

For the first case,
- create several types of files on ubifs (regular file, dir, char dev,
  block dev, fifo, symlink, socket).
- issue stat(2), fstat(2), lstat(2) to them on ubifs.
- repeat the same procedure on aufs which has ubifs as the branch, and
  of course the branch should contain these files.
- compare the results.

For the second case,
- mount aufs with ubifs as the first writable branch, without the
  explicit xino=PATH option.
- check its XINO files, its path, blocks and size, by /sys/fs/aufs/* or
  /debug/fs/aufs/*.
- repeat the same procedure, but WITH xino=PATH option. the path will be
  ubifs.
- in every case, aufs should reject creating XINO on ubifs.

J. R. Okajima

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

Re: ubifs doesn't maintain i_blocks.

sfjro <at> users.sourceforge.net:
> The main purpose of the tests will be
> - stat(2) familly in aufs should return the same value to the one in
>   ubifs.
> - aufs should not create the XINO files on ubifs.

The second case was unnecessary since aufs already handled it.

J. R. Okajima

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

Problem with aufs on top of hfsplus(ro) and ext3(rw): any client process hangs when performing a file rename

Hello,

I would like to inform you about a problem I have systematically when
using aufs on top of a read-only hfsplus filesystem.
It occurs everytime the shell or any process tries to rename a file
located in the aufs filesystem: the process then gets hanged in a non
interruptible system call (called by the hfsplus module).

Because of this my feeling is that the problem comes more from the
hfsplus module than from aufs. But on the other hand, this problem is
not present when using the unionfs module instead of aufs. Because of
this, I was previously using unionfs instead of aufs when on Ubuntu
9.04, but now, on Ubuntu 9.10 I can't do it anymore because unionfs is
not packaged in ubuntu anymore.

I would really like to use aufs and to find a workaround to this
problem, which could either be a patch to the aufs module source code,
or trying different aufs module configuration parameters, or mounting
parameters.

Please could you have a look at all the details about my problem below?
I am available to give you other details you would need, and also to
proceed to other tests, like testing a patch.

I work on a Mac Pro computer on which I have a double boot: OSX / Ubuntu
9.10. My OSX home folder is on a hfsplus partition, and my Ubuntu home
under a ext3 partition.
When working on Linux, I mount the hfsplus partition in read-only mode,
and try to use aufs, so as to make the OSX home appear as a writable
partition.

Re: ubifs doesn't maintain i_blocks.

Hi,

On Mon, Mar 1, 2010 at 9:45 PM,  <sfjro <at> users.sourceforge.net> wrote:
>
> Joonwoo Park:
>> So about this change can you suggest me any test cases?
>> Until now I'm running bonnie++ and an application to test mmap functionality.
>
> The main purpose of the tests will be
> - stat(2) familly in aufs should return the same value to the one in
>  ubifs.
> - aufs should not create the XINO files on ubifs.
>
> For the first case,
> - create several types of files on ubifs (regular file, dir, char dev,
>  block dev, fifo, symlink, socket).
> - issue stat(2), fstat(2), lstat(2) to them on ubifs.
> - repeat the same procedure on aufs which has ubifs as the branch, and
>  of course the branch should contain these files.
> - compare the results.

Thanks for your detail explanation.
I briefly ran that test case and it worked fine.
However unlikely I excepted that it shouldn't work without patch, even
without patch I could get correct result.
Is it possible to work without patch even though i_blockes is not
being preserved?

Thanks,
Joonwoo

Re: Problem with aufs on top of hfsplus(ro) and ext3(rw): any client process hangs when performing a file rename

Hello Ananda,

Ananda Tallur:
> I would like to inform you about a problem I have systematically when
> using aufs on top of a read-only hfsplus filesystem.
> It occurs everytime the shell or any process tries to rename a file
> located in the aufs filesystem: the process then gets hanged in a non
> interruptible system call (called by the hfsplus module).

Thank you for the detailed report.
hfsplus seems to acquire an inode mutex lock when closing a file. It is
an unexpected behaviour for aufs, but it is NOT a problem of hfsplus.
Here is a patch for you.
Please test it. I will test it by myself tommorrrow probably.
Also I'd suggest you to upgrade your aufs to the latest version.

J. R. Okajima

------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev