Re: ext3/ext2 kernel bug with umlauts?
Ted,
There have been some reports on debian-arm recently about problems
with ext3: some files containg special characters (e.g. umlauts) don't
show up properly, and the problem goes away when the filesystem is
mounted as ext2.
Some examples and information:
* Kai Weber <kai.weber@glorybox.de> [2008-08-16 22:03]:
> I have an Debian/NSLU2, kernel 2.6.18-6-ixp4xx.
>
> Following interesting problem. Could this be a kernel bug? If I attach
> the USB disk to my laptop it works flawless whether mounted as ext3 or
> ext2.
>
> $ uname -a
> Linux foobar 2.6.18-6-ixp4xx #1 Wed Jun 18 23:27:34 UTC 2008 armv5tel
> GNU/Linux
> $ mount | grep /share
> /dev/sdb6 on /share type ext3 (rw)
> $ ls /share/erlend*
> ls: /share/erlend Øye - dj kicks: No such file or directory
> $ sudo umount /share
> $ sudo mount -t ext2 /dev/sdb6 /share
> $ ls /share/erlend*
> total 76892
> 01-jürgen_paape-so_weit_wie_noch_nie.mp3
> 03-erlend_øye-sheltered_life_(rmx)+fine_night_(acapella).mp3
> [...]
Micha <post@glockenstein.de> confirms the same problem with 2.6.26.
Timo Jyrinki reported something similar in #493957 and provides a lot
of information:
> - However, some directories were not accessible. All unaccessible
> directories seemed to (at a casual look) have special characters in
> their names, but many similar named directories worked without problems.
> For example (from my FLACd CD collection):
> d????????? ? ? ? ? ? Björk - Telegram
> d????????? ? ? ? ? ? Ø - Metri
> etc.
[After upgrading from 2.6.25 to 2.6.26:]
> However, I still have the same problem with some of the directories on the
> disk, regardless of whether it's attached via USB or eSATA. I tried the
> following, all actions done on my laptop and then checked the result when
> attaching the disk to the QNAP:
> 1. Tarring a few problematic directories and untarring on ext3-formatted
> USB stick, same directory structure
> : Does not show the problem on the USB stick.
> 2. As above, but untarring on the same disk in different directory
> : Does not show the problem
> 3. As above, but removing the problematic dirs in place and untarring from
> the archive
> : The problematic directories stay problematic
> 4. Moving a few problematic dirs to another directory
> : They start working
> 5. Creating a few additional dirs in the original directory, then moving
> the moved directories back to the original directory too
> : The created dirs work, but the moved-back dirs are again problematic
> 6. Sorted by inode ls -i, the problematic dirs are not sequential.
>
> Ok, so I couldn't figure out anything, but now while I'm writing this I
> tried ls -U, ie. unsorted ls, and found out that all the problematic dirs
> are in sequential order, with line numbers 60-68. There was actually a
> ninth problematic directory, which I moved now away while testing. But now
> there are only eight problematic dirs.
> It does not seem to be related to those index numbers though, since I
> found other unaccessible subdirectories in other places. Curiously, I
> found that I had two subdirectories under different directories which had
> the same name "näytettävät" ("to be shown"), and both of them were
> unaccessible. Both of them were second of two subdirectories (among files)
> respectively, when viewing with ls -U.
> Attached is output (cutted in places marked as such) of ls -l and ls -U
> in the original problematic directory.
> Can you think of anything that could cause the problem, or any low level
> information on those directory entries I could somehow extract?
> As a sidenote, as only stderr messages have correctly formed non-ascii
> characters, kernel / something seems to lack some charset support. When
> going into directories with eg. cd A[tab], non-ascii characters are
> correctly shown.
and:
> I tested attaching another disk to QNAP, a disk that happens to have an
> earlier backup of the same CD FLAC rips... the same problems show there,
> ie. 10 unaccessible sequential (ls -U) directories under that
> subdirectory. Different directories this time, so it's not about the
> contents, but some other feature / index of those. Also on the same disc
> are a few other unaccessible directories, but that's the only directory
> with so many subdirectories that the "10 in a row" thing is visible.
and:
> > Timo, can you try to mount the filesystem as ext2 (rather than ext3)
> > and tell me whether you still see this problem.
> Right, that solves the problem. Mounting as ext2 works, mounting as ext3
> gives the problems described in my bug report and on the mailing list by
> Kai.
> I've not been able to reproduce the problem by any simple empty file /
> directory creation. Even with the same directory structure, I cannot see the
> problem if the data is not there. And I cannot see the problem if I just copy
> the "problematic" (on that disk) entries/dirs. I also tried using a script to
> create directories with entries beginning with "ä" in fi-wiktionary, but they
> also look fine when connected to QNAP.
> It does not look like any corruption on the HDD I'm using either, since the
> same data backuped to another disc shows the same problem in the same
> directory/directories, although for different entries. Both disks can be
> accessed fine when mounted as ext3 to other machines.
> > What is the output of 'locale'?
> fi_FI.UTF-8 on all lines (except the last LC_ALL which is empty). I tried
> export LANG=C (which changes all output lines of locale to C) before
> mounting but at least that didn't change anything.
--
Martin Michlmayr
http://www.cyrius.com/
Reply to: