<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user">
    <title>gmane.linux.file-systems.aufs.user</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4310"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4309"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4308"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4307"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4306"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4305"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4304"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4303"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4302"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4301"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4300"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4299"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4298"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4297"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4296"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4295"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4294"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4293"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4292"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4291"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4310">
    <title>Re: Error: cannot access file: Object is Remote</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4310</link>
    <description>&lt;pre&gt;
Hello Ken,


Not intentional.
Something is wrong. Let's confirm the behaviour step by step.
What will happen if you run "ls A" and "ls B" individually?


J. R. Okajima

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev

&lt;/pre&gt;</description>
    <dc:creator>sfjro&lt; at &gt;users.sourceforge.net</dc:creator>
    <dc:date>2013-06-19T11:07:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4309">
    <title>Error: cannot access file: Object is Remote</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4309</link>
    <description>&lt;pre&gt;Hello,

We're testing AUFS in Ubuntu 13.04 Raring, and are finding that it has a
different behavior than in Ubuntu 12.04 Precise. The version of AUFS in
Raring is 3.8, while it is 3.2 in Precise. The test case is simple:

$ mount -t aufs -o dirs=A:B aufs C

Directory A is the RW mount, which is no more than an empty directory.
Directory B is the RO mount, which happens to sit on our distributed file
system (OpenAFS). Directory C is the mount point.

In Precise, directory C works correctly. All files are visible, and
modifications can be made. In Raring, directory C does not work. When
performing any operation in the directory, such as "ls", we get the error
"ls: cannot access XYZ: Object is remote".

Was this an intentional change in behavior? Is there any way I can revert
it to the Precise behavior?

Best,
Ken

   Hello,
   We're testing AUFS in Ubuntu 13.04 Raring, and are finding that it has a
   different behavior than in Ubuntu 12.04 Precise. The version of AUFS in
   Raring is 3.8, while it is 3.2 in P&lt;/pre&gt;</description>
    <dc:creator>Ken Elkabany</dc:creator>
    <dc:date>2013-06-19T08:01:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4308">
    <title>Re: Force writing to a particular branch</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4308</link>
    <description>&lt;pre&gt;
David De Weerdt:

Then why do you put tmpfs as the first writable branch?


J. R. Okajima

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j

&lt;/pre&gt;</description>
    <dc:creator>sfjro&lt; at &gt;users.sourceforge.net</dc:creator>
    <dc:date>2013-06-04T15:43:08</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4307">
    <title>Re: Force writing to a particular branch</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4307</link>
    <description>&lt;pre&gt;Hello,

Thank you for your response.

But I don't understand what you need. What and how do you think the rule

Basically the rule would be very simple. I want everything to be written to
a specific (for example the second) branch, irregardless whether the other
branch(es) are writable or not.

Greetings,
David

   Hello,
   Thank you for your response.

     But I don't understand what you need. What and how do you think the rule
     to choose your writable branch, which aufs can implement?

   Basically the rule would be very simple. I want everything to be written to
   a specific (for example the second) branch, irregardless whether the other
   branch(es) are writable or not.
   Greetings,
   David
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT &lt;/pre&gt;</description>
    <dc:creator>David De Weerdt</dc:creator>
    <dc:date>2013-06-04T15:38:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4306">
    <title>Re: Force writing to a particular branch</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4306</link>
    <description>&lt;pre&gt;
Hello David,

David De Weerdt:

You can make a trick for the default policy 'top-down-parent'.
- you have two writable branches
- mkdir a directory on the lower branch
  for example, if you want to put dirA/fileB on the lower branch, then run
  "mkdir /lower/dirA". in this situation, when you try creating dirA/fileB,
  aufs finds that dirA already exists on the lower writable branch and
  the 'top-down-parent' policy will choose it as the target branch.

But this approach may be unusable for you since you have to mkdir
several times. So you may want another one. For instance, the copy-down
or move-down feature may sound good for you (while they are just plan).
But I don't understand what you need. What and how do you think the rule
to choose your writable branch, which aufs can implement?

By the way, I have a plan to implement a new option to specify the
priority of the writable branches for a long time, and it is still just
a plan.


J. R. Okajima

---------------------------------------------------------&lt;/pre&gt;</description>
    <dc:creator>sfjro&lt; at &gt;users.sourceforge.net</dc:creator>
    <dc:date>2013-06-04T15:29:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4305">
    <title>Force writing to a particular branch</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4305</link>
    <description>&lt;pre&gt;Hello,

Suppose I have an aufs with two rw-mounted branches. Is it possible to
force writing to only the second branch, even if does not have the most
free space?

Background:
I have a setup with an SSD as main storage. However, almost never I want to
write to this SSD. So I mount this with "mount -t aufs -o
br=/tmpfs=rw:/ssddisk=ro none / " . This ensures that writes are done to a
tmpfs.

When I do want to write to disk, I do a  "mount -t aufs -o
remount,mod:ssddisk=rw none /".  However, this still writes to /tmpfs as it
is the first branch. When I add "create=mfs", this only writes to my
/ssddisk while it has more free space than the /tmpfs. Remounting /tmpfs to
ro is also not an option, as I get an E_BUSY error message.

Thanks,
David

   Hello,
   Suppose I have an aufs with two rw-mounted branches. Is it possible to force
   writing to only the second branch, even if does not have the most free
   space?
   Background:
   I have a setup with an SSD as main storage. However, almost never I want to
   wri&lt;/pre&gt;</description>
    <dc:creator>David De Weerdt</dc:creator>
    <dc:date>2013-06-04T08:37:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4304">
    <title>aufs3 GIT release</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4304</link>
    <description>&lt;pre&gt;
o news
- copyup supports for a sticky bit of the parent
  As three users posted about this issue to the aufs-users ML, I
  implemented a workaround. But I am not sure this is correct. It means
  that this commit may be reverted in the future.

J. R. Okajima

----------------------------------------------------------------------
- aufs3-linux.git#aufs3.2..aufs3.9 branch
      aufs: copyup supports for a sticky bit of the parent

- aufs3-linux.git#aufs3.x-rcN branch
  Addition to above,
      aufs: for linux-3.10, tiny, include aio.h

- aufs3-standalone.git
  ditto

- aufs-util.git
  none

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

&lt;/pre&gt;</description>
    <dc:creator>sfjro&lt; at &gt;users.sourceforge.net</dc:creator>
    <dc:date>2013-05-19T19:37:07</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4303">
    <title>Re: Re: simple noob question</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4303</link>
    <description>&lt;pre&gt;
Sorry interrupting ML.

To: q5sys &amp;lt;q5sys&amp;lt; at &amp;gt;users.sourceforge.net&amp;gt;

I replied to your personal mail, but it was bounced because of

&amp;lt;q5sys&amp;lt; at &amp;gt;users.sourceforge.net&amp;gt;: host mx.sourceforge.net[216.34.181.68] said: 550
    unknown user (in reply to RCPT TO command)

Here I forward my reply to this ML with a little hope to reach you.


------- Forwarded Message

From: sfjro&amp;lt; at &amp;gt;users.sourceforge.net
Subject: Re: simple noob question
To: q5sys &amp;lt;q5sys&amp;lt; at &amp;gt;users.sourceforge.net&amp;gt;
Date: Fri, 17 May 2013 14:19:58 +0900
Message-ID: &amp;lt;23331.1368767998&amp;lt; at &amp;gt;jrobl&amp;gt;


Hello q5sys,

q5sys:

Unfortunately I could not fully understand what you wrote.
But I hope that the aufs README file will help you to understand what
aufs3-linux.git and aufs3-standalone.git are.
You can read the README file via http://aufs.sf.net.


J. R. Okajima

------- End of Forwarded Message


------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the e&lt;/pre&gt;</description>
    <dc:creator>sfjro&lt; at &gt;users.sourceforge.net</dc:creator>
    <dc:date>2013-05-17T05:33:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4302">
    <title>Re: [SOLVED] Errors on compile 3.4.42 kernel with RT patch and AUFS</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4302</link>
    <description>&lt;pre&gt;
Daniel Vidal:

For the member 'owner', while the original struct mutex definition has a
preproessor condition, struct rtmutex doesn't.

struct mutex {
:::
#if defined(CONFIG_DEBUG_MUTEXES) || defined(CONFIG_SMP)
struct task_struct*owner;
#endif
:::
};

and

struct rt_mutex {
:::
struct task_struct*owner;
:::
}

So it might be better to use i_mutex.lock.owner regardless CONFIG_DEBUG_MUTEXES
and CONFIG_SMP.
Additionally rtmutex.c defines rt_mutex_set_owner() and you should call
it instead of assgin directly I think.
Obviously you should test it well.


J. R. Okajima

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

&lt;/pre&gt;</description>
    <dc:creator>sfjro&lt; at &gt;users.sourceforge.net</dc:creator>
    <dc:date>2013-05-15T12:58:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4301">
    <title>Re: [SOLVED] Errors on compile 3.4.42 kernel with RT patch and AUFS</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4301</link>
    <description>&lt;pre&gt;Hi.

Well I try with this version of kernel because this branch is the newest
marked "longterm" in kernel.org.

The rt patch is also downloaded from kernel.org. The exact URL is:

https://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patch-3.4.42-rt57.patch.gz

Thanks in advance.


2013/5/14 &amp;lt;sfjro&amp;lt; at &amp;gt;users.sourceforge.net&amp;gt;


   Hi.
   Well I try with this version of kernel because this branch is the newest
   marked "longterm" in [1]kernel.org.
   The rt patch is also downloaded from [2]kernel.org. The exact URL is:
   [3]https://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patch-3.4.42-rt57
   .patch.gz
   Thanks in advance.

   2013/5/14 &amp;lt;[4]sfjro&amp;lt; at &amp;gt;users.sourceforge.net&amp;gt;

     Hello Daniel,
     Daniel Vidal:

   &amp;gt; I had problems when trying to compile a 3.4.42 kernel with real time and
   &amp;gt; aufs patch.

     As you might know, aufs is for the mainline linux kernel only.
     So it doesn't surprise me that you met a compile error.

   &amp;gt; au_pin_hdir_set_owner void (struct au_pin * p, struct task_struct * &lt;/pre&gt;</description>
    <dc:creator>Daniel Vidal</dc:creator>
    <dc:date>2013-05-14T18:50:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4300">
    <title>Re: [SOLVED] Errors on compile 3.4.42 kernel with RT patch and AUFS</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4300</link>
    <description>&lt;pre&gt;
Hello Daniel,

Daniel Vidal:

As you might know, aufs is for the mainline linux kernel only.
So it doesn't surprise me that you met a compile error.



I see.
I understand what you did. But I am not sure whether it is correct or
not because I don't know which RT patch you are using.
'#ifdef' you added highly depends upon the RT patch.

If you are asking me the code review, then tell me the version of RT
patch you are using and the URL where I can get it.


J. R. Okajima

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

&lt;/pre&gt;</description>
    <dc:creator>sfjro&lt; at &gt;users.sourceforge.net</dc:creator>
    <dc:date>2013-05-14T18:16:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4299">
    <title>[SOLVED] Errors on compile 3.4.42 kernel with RT patch and AUFS</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4299</link>
    <description>&lt;pre&gt;Hi sfjro!

I had problems when trying to compile a 3.4.42 kernel with real time and
aufs patch.

The file that failed was i_op.c.

The message was that "struct mutex" did not have "owner" field.

I reviewed the patch RT and found that changes "struct mutex" adding a
level.

"struct mutex" is defined as:

struct mutex {
         rt_mutex struct lock;
# ifdef CONFIG_DEBUG_LOCK_ALLOC
         struct lockdep_map dep_map;
# endif
};

It is in the definition of rt_mutex where it appears "owner".

I modified the function that gave trouble this way:

au_pin_hdir_set_owner void (struct au_pin * p, struct task_struct * task)
{
# if defined (CONFIG_DEBUG_MUTEXES) | | defined (CONFIG_SMP)
# if defined (CONFIG_PREEMPT_RT_FULL)
         p-&amp;gt; hdir-&amp;gt; hi_inode-&amp;gt; i_mutex.lock.owner = task;
# else
         p-&amp;gt; hdir-&amp;gt; hi_inode-&amp;gt; i_mutex.owner = task;
# endif
# endif
}

Now compiles without errors and everything seems ok.

Attached a patch to that file for your review.

(translated with google... i'am sorry)

   Hi sfjro!
   I ha&lt;/pre&gt;</description>
    <dc:creator>Daniel Vidal</dc:creator>
    <dc:date>2013-05-14T18:06:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4298">
    <title>Re: Kernel 3.9 noplink problem [SOLVED]</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4298</link>
    <description>&lt;pre&gt;
(CC-ed Francois and Justin)

Klaus Knopper:

I see.
I decided implementing a workaround for this problem and release next
Monday.


J. R. Okajima

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

&lt;/pre&gt;</description>
    <dc:creator>sfjro&lt; at &gt;users.sourceforge.net</dc:creator>
    <dc:date>2013-05-14T04:11:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4297">
    <title>Re: Kernel 3.9 noplink problem [SOLVED]</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4297</link>
    <description>&lt;pre&gt;Hello Junjiro,

Thanks fpr pointing this out. I was not aware that I had hit the same
problem with a (seemingly) different scenario. This is new to me, since
until now, I had always used the sticky bit on the overlay branch and
never occured permission problems that resulted in I/O errors. Also, I
always use noplink because I did not need any.

On Tue, May 14, 2013 at 10:57:51AM +0900, sfjro&amp;lt; at &amp;gt;users.sourceforge.net wrote:

I have not seen that message "I/O Error, failed removing broken
entry(-1, -1)" in dmesg, but mode=0755 in my initrd (where I set up the
aufs stack) actually fixes the problem.

As for your question in the recent thread reply
http://www.mail-archive.com/aufs-users&amp;lt; at &amp;gt;lists.sourceforge.net/msg04203.html
("Hmm... what should I do..."), I have no perfect answer. If it is
documented that sticky bits on the writable branch only (which is
default for tmpfs unfortunately) are bad, it's fine with me, but I think
that at least the dmesg error message is somewhat misleading and should
rather say something&lt;/pre&gt;</description>
    <dc:creator>Klaus Knopper</dc:creator>
    <dc:date>2013-05-14T02:48:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4296">
    <title>Re: Kernel 3.9 noplink problem</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4296</link>
    <description>&lt;pre&gt;
Hi Klaus,

Klaus Knopper:

If the message is preceeded by "I/O Error, failed removing broken
entry(-1, -1)" and the sticky bit is set to your upper RW layer, then
I'd suggest you to try "chmod -t /ramdisk" or "mount -t tmpfs -o
mode=0755 tmpfs /ramdisk" after reading
http://www.mail-archive.com/aufs-users&amp;lt; at &amp;gt;lists.sourceforge.net/msg04202.html
and its thread.


J. R. Okajima

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

&lt;/pre&gt;</description>
    <dc:creator>sfjro&lt; at &gt;users.sourceforge.net</dc:creator>
    <dc:date>2013-05-14T01:57:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4295">
    <title>Re: I/O Error, i46 exists on a upper branch but not pseudo-linked</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4295</link>
    <description>&lt;pre&gt;
Francois Goudal:

Instead of chmod, try the tmpfs mount option "mode=xxx". Probably
"mode=0755" is good for you.


J. R. Okajima

------------------------------------------------------------------------------
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d

&lt;/pre&gt;</description>
    <dc:creator>sfjro&lt; at &gt;users.sourceforge.net</dc:creator>
    <dc:date>2013-05-14T01:51:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4294">
    <title>Kernel 3.9 noplink problem</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4294</link>
    <description>&lt;pre&gt;Hi,

On Mon, May 06, 2013 at 10:36:02AM +0900, sfjro&amp;lt; at &amp;gt;users.sourceforge.net wrote:

Could it be that this simplification broke the "noplink" mount option in
aufs3.9 for Kernel 3.9? I get I/O errors, and dmesg tells me that
"au_cpup_single: hi&amp;lt;number&amp;gt; exists on b0 but plink is disabled".

The message is wrong in every way, since hapens when I copy a new file
to the aufs mountpoint, which definitely does NOT already exist on the
writable branch 0.

My aufs config:
CONFIG_AUFS_FS=y
CONFIG_AUFS_BRANCH_MAX_127=y
# CONFIG_AUFS_BRANCH_MAX_511 is not set
# CONFIG_AUFS_BRANCH_MAX_1023 is not set
# CONFIG_AUFS_BRANCH_MAX_32767 is not set
CONFIG_AUFS_SBILIST=y
# CONFIG_AUFS_HNOTIFY is not set
CONFIG_AUFS_EXPORT=y
CONFIG_AUFS_INO_T_64=y
# CONFIG_AUFS_RDU is not set
CONFIG_AUFS_PROC_MAP=y
# CONFIG_AUFS_SP_IATTR is not set
# CONFIG_AUFS_SHWH is not set
CONFIG_AUFS_BR_RAMFS=y
CONFIG_AUFS_BR_FUSE=y
CONFIG_AUFS_POLL=y
CONFIG_AUFS_BR_HFSPLUS=y
CONFIG_AUFS_BDEV_LOOP=y

My mount tree:
mount -t aufs -o br:/ramdisk=rw:/KNOPPIX=ro,&lt;/pre&gt;</description>
    <dc:creator>Klaus Knopper</dc:creator>
    <dc:date>2013-05-13T19:51:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4293">
    <title>Re: I/O Error, ... exists on a upper branch but not pseudo-linked</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4293</link>
    <description>&lt;pre&gt;
:::

We found that his problem is related to the sticky bit of the upper RW
branch dir, and could solve (at least, workaround) it.

Justin, if you are using tmpfs and its sticky bit is set, I'd suggest
you to drop it.

I have downloaded your iso image, but don't have time to test
it. Currently my test machine is working very busy for testing
linux-3.10-rc1.


J. R. Okajima

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

&lt;/pre&gt;</description>
    <dc:creator>sfjro&lt; at &gt;users.sourceforge.net</dc:creator>
    <dc:date>2013-05-13T15:37:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4292">
    <title>Re: I/O Error, i46 exists on a upper branch but not pseudo-linked</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4292</link>
    <description>&lt;pre&gt;
Francois Goudal:

Glad to hear that!



Thanks but it won't be necessary because I think I can reproduce the
problem on my test machine.
What I am thinking now is
- aufs should respect the native feature (including security) of the
  branch fs as possible.
- as long as the sticky bit is set to the branch, aufs should follow the
  behaviour of the branch fs (which causes an error in this case).
- on the other hand, the copy-up should be done internally and
  transparently (from the users' view). It means aufs should break the
  sticky bit protection.
- actually the old versions of aufs didn't issue the rename operation as
  a part of the copy-up and this problem didn't happen ever.

Hmm... what should I do...


J. R. Okajima

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the f&lt;/pre&gt;</description>
    <dc:creator>sfjro&lt; at &gt;users.sourceforge.net</dc:creator>
    <dc:date>2013-05-13T15:02:24</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4291">
    <title>Re: I/O Error, i46 exists on a upper branch but not pseudo-linked</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4291</link>
    <description>&lt;pre&gt;Le 13/05/13 16:07, sfjro&amp;lt; at &amp;gt;users.sourceforge.net a écrit :
Ah ok, my bad. Yes, you are right. So my /ramvar should have the same 
permissions as the original /var basically, and it is not the case for 
some reason.
So when I make the union of /var and /ramvar, the result inherits from 
the sticky bit of /ramvar and this creates some mess afterwards.

I just figured out that my /ramvar has correct permissions, but as soon 
as I mount a tmpfs on it, it gets rwxrwxrwt
I have now updated my init script that is responsible for mounting all 
the aufs and aufs-related stuff, I do a chmod after I mount the tmpfs to 
/ramvar and the problem is now gone.

Thank you very much for your help, much appreciated.
Still, I guess, there is still a problem with copyup not being able to 
support such a strange case. Should you need me to make some more tests, 
let me know and I will of course do it.

Best regards,

&lt;/pre&gt;</description>
    <dc:creator>Francois Goudal</dc:creator>
    <dc:date>2013-05-13T14:21:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4290">
    <title>Re: I/O Error, i46 exists on a upper branch but not pseudo-linked</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.aufs.user/4290</link>
    <description>&lt;pre&gt;
Francois Goudal:

According to the debug output, the sticky bit is set to your /varram.
Your /var is /var(ro) and /varram(rw), right?


J. R. Okajima

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

&lt;/pre&gt;</description>
    <dc:creator>sfjro&lt; at &gt;users.sourceforge.net</dc:creator>
    <dc:date>2013-05-13T14:07:40</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.file-systems.aufs.user">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.file-systems.aufs.user</link>
  </textinput>
</rdf:RDF>
