"Jrgen_P._Tjern":
> getting "aufs au_new_inode:...: broken ino", e.g.:
> [ 349.301408] aufs au_new_inode:325:glftpd[3180]: broken ino, b0,
> files/3.Lbs, hi805306524, i1078. Try udba=3Dinotify.
> Also:
> [631021.668293] aufs au_new_inode:325:twistd[27583]: broken ino, b0,
> libxtst/libxtst6_1.0.1-3build1_i386.deb, hi134217865, i48493. Try
> udba=3Dinotify.
> [717395.849214] aufs au_new_inode:325:twistd[27583]: broken ino, b0,
> samba/samba-common_3.0.22-1ubuntu4.2_i386.deb, hi134217862, i48869. Try
> udba=3Dinotify.
:::
> What's the cause? Is this a problem?
It must be a probelm for aufs, but it may not be for you.
It means,
"aufs tries assigning 48869 as the aufs inode number for
samba/samba-common_3.0.22-1ubuntu4.2_i386.deb whose inode number is
134217862 on branch 0 (the first branch) since 48869 was previously
assigned for 134217862. But current aufs inode #48869 has different
information and aufs thinks it was changed by someone else outside
aufs. To detect the outer changes, udba=inotify is necessary."
Then aufs assigns another inode number. You can continue accessing
the reported file flawlessly, but its inode number is changed. Some
applications, such like "chmod -R xxx /large/dir", may warn about that.
Actually you already specified udba=inotify, so it must be a bug.
Additionally the inode numbers #805306524, #134217865 and #134217862
seem to be too large. Are they correct numbers? Generally speaking, they
are not illegal numbers, but I want to check whether they are correct or
not.
Please tell me about your branch 0. What filesystem is it? What is the
largest inode number on it?
Junjiro Okajima
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
