By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.

Bug 1758

Summary:	Amarok (x86) fails scanning files whose inode value exceeds "uint32 max value" (XFS/inode64).
Product:	TDE	Reporter:	Nicolas Bercher <nbercher>
Component:	non-core programs	Assignee:	Timothy Pearson <kb9vqf>
Status:	NEW ---
Severity:	normal	CC:	bugwatch, nbercher, slavek.banko
Priority:	P5
Version:	3.5.13.x [Trinity]
Hardware:	i386
OS:	Debian Squeeze
Compiler Version:		TDE Version String:
Application Version:	4:3.5.13.2-0debian6.0.0+1	Application Name:	Amarok

Description Nicolas Bercher 2013-12-06 07:42:44 CST

This bug has been noted in a client(x86)-server(x86) context for files served over NFS3 using XFS/inode64 backend volume.

* Server side:
A x86 Debian Squeeze server serves audio files over NFS3.  Files are stored on a XFS partition mounted using the inode64 option.
(XFS inode64 option has been enabled to overcome the 1TB limitation of XFS[1].  After that, most of newer files would have "64bits inodes", inodes whose values are greater than 2^32-1.  The older files remain with their "32 bits inodes", with values smaller than 2^32.)

* Client side:
Laptop running Debian Squeeze using Trinity 3.5.13.2 that connects to the NFS server in order to listen to music using Amarok (amarok-trinity x86 4:3.5.13.2-0debian6.0.0+1).

* Problem: amarok is only able to scan files whose inode values are
smaller than the "uint32 max value" (2^32).

The problem does not affect amarok-trinity on amd64 clients connected through NFS3 to x86 or amd64 servers that both use XFS/inode64 volumes.

--
[1] http://xfs.org/index.php/XFS_FAQ#Q:_What_is_the_inode64_mount_option_for.3F

Comment 1 Nicolas Bercher 2013-12-06 07:45:17 CST

I suspect that every x86 versions of amarok-trinity are concerned.

Comment 2 Slávek Banko 2013-12-06 08:28:54 CST

I assume that the server is x64. As far as I know, on x86 kernel can not be
used inode64 option.

Comment 3 Nicolas Bercher 2013-12-06 08:41:31 CST

(En réponse au commentaire 2)
> I assume that the server is x64. As far as I know, on x86 kernel can not be
> used inode64 option.

Please, re-read the bug description because all your assumptions are wrong.

Comment 4 Nicolas Bercher 2013-12-06 08:44:19 CST

(En réponse au commentaire 3)
> (En réponse au commentaire 2)
> > I assume that the server is x64. As far as I know, on x86 kernel can not be
> > used inode64 option.
> 
> Please, re-read the bug description because all your assumptions are wrong.

Just to fix things: this is all on the server (it also mounts itself over NFS as another x86 client):

$ mount | grep inode64
/dev/mapper/tetra02-home on /home type xfs (rw,inode64)
$ uname -r
3.2.0-0.bpo.2-686-pae

Comment 5 Slávek Banko 2013-12-06 08:48:04 CST

(Odpověď na komentář #4)
> (En réponse au commentaire 3)
> > (En réponse au commentaire 2)
> > > I assume that the server is x64. As far as I know, on x86 kernel can not be
> > > used inode64 option.
> > 
> > Please, re-read the bug description because all your assumptions are wrong.
> 
> Just to fix things: this is all on the server (it also mounts itself over NFS
> as another x86 client):
> 
> $ mount | grep inode64
> /dev/mapper/tetra02-home on /home type xfs (rw,inode64)
> $ uname -r
> 3.2.0-0.bpo.2-686-pae

Aha - kernel from backports is the explanation.

Comment 6 Nicolas Bercher 2013-12-06 11:10:33 CST

(En réponse au commentaire 5)
> (Odpověď na komentář #4)
> > (En réponse au commentaire 3)
> > > (En réponse au commentaire 2)
> > > > I assume that the server is x64. As far as I know, on x86 kernel can not be
> > > > used inode64 option.
> > > 
> > > Please, re-read the bug description because all your assumptions are wrong.
> > 
> > Just to fix things: this is all on the server (it also mounts itself over NFS
> > as another x86 client):
> > 
> > $ mount | grep inode64
> > /dev/mapper/tetra02-home on /home type xfs (rw,inode64)
> > $ uname -r
> > 3.2.0-0.bpo.2-686-pae
> 
> Aha - kernel from backports is the explanation.

Come on, are you serious?

I had the same issues with all of these kernels:

$ aptitude search ~i~nlinux-image -F "%p"
linux-image-2.6-686
linux-image-2.6.26-2-686
linux-image-2.6.32-5-686
linux-image-2.6.32-bpo.5-686
linux-image-3.2.0-0.bpo.2-686-pae

Comment 7 Slávek Banko 2013-12-08 08:10:20 CST

(Odpověď na komentář #6)
> Come on, are you serious?
> 
> I had the same issues with all of these kernels:
> 
> $ aptitude search ~i~nlinux-image -F "%p"
> linux-image-2.6-686
> linux-image-2.6.26-2-686
> linux-image-2.6.32-5-686
> linux-image-2.6.32-bpo.5-686
> linux-image-3.2.0-0.bpo.2-686-pae

Ok, I overslept time - inode64 can be used on 32bit kernels since 2.6.29.

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6c31b93a

Comment 8 Nicolas Bercher 2013-12-09 08:19:35 CST

(En réponse au commentaire 7)
> (Odpověď na komentář #6)
> Ok, I overslept time - inode64 can be used on 32bit kernels since 2.6.29.
> 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6c31b93a

Interesting link.  I suppose that amarok-trinity x86 relies on
libraries that raises EOVERFLOW, while le amd64 version does not.
Do you follow/agree with me?

Note this fact:
I...
  1. ran an amd64 Debian LiveCD on my laptop,
  2. Installed almarok-trinity (amd64) on it,
  3. Connected the laptop the the x86/NFS/XFS/Inode64 folder,
  4. asked Amarok to rescan the while MP3s collection.

Then I got an up-to-date collection.db file.

  5. copied "amd64 collection.db" in place of the "x86 outdated
     collection.db",
  6. changed some wrong ID3 tags under the amd64 amarok,
  7. rebooted using the normal x86 Debian install on the laptop.

After all of that, I ended up (of course) with the "amd64
collection.db" used by Amarok x86 *not updated regarding step 7.*
(which was applied on files with inode>2^32).
And as usual, Amarok x86 wasn't able to update collection.db regarding
changes that occured in step 7.  But everything except that worked
fine (opening files to listening to music).

So the bug might come from the library that open/read audio files on
behalf of the ID3tag retriever (somewhere around metabundle,
TagLib::ID3v2 ?).

Could files be opened differently under 32 bits ad 64 bits
architectures?