linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* kernel 2.6.4: Bug in JFS file system?
@ 2004-03-23 18:55 Andreas Theofilu
  2004-03-24 13:45 ` Dave Kleikamp
  0 siblings, 1 reply; 3+ messages in thread
From: Andreas Theofilu @ 2004-03-23 18:55 UTC (permalink / raw)
  To: linux-kernel

Hi to all,

Since kernel 2.6.4 I'm not able to access files with a special character
in the file name, such as the german umlaute. Every attempt to access such
a file gives me the error: cannot stat file

I'm using several partitions with JFS file system and had never seen such
a strange behavior before. The relevant kernel settings are at the bottom
of the mail.

I already unmounted the partition and run fsck on it (fsck.jfs -f
/dev/hda8), but it told me that everything is ok and I'm still not able to
access this files. Also a reboot of the machine didn't change anything. I
booted 2.6.3 again and renamed the files in question (no more special
characters in the file name). Now I can access these files with 2.6.4
also.

Allthough I'm a programmer, I'm not a kernel hacker and don't know where
to start looking for this problem. Could anybody give me a hint where to
start looking?

-------------------------
Kernel 2.6.4 settings (.config)
#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
CONFIG_JFS_FS=y
CONFIG_JFS_POSIX_ACL=y
# CONFIG_JFS_DEBUG is not set
CONFIG_JFS_STATISTICS=y
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
CONFIG_MINIX_FS=y
# CONFIG_ROMFS_FS is not set
CONFIG_QUOTA=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_AUTOFS_FS=y
CONFIG_AUTOFS4_FS=y

-- 
Andreas Theofilu
http://www.TheosSoft.net/

                     --==| Enjoy the science of Linux! |==--

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: kernel 2.6.4: Bug in JFS file system?
  2004-03-23 18:55 kernel 2.6.4: Bug in JFS file system? Andreas Theofilu
@ 2004-03-24 13:45 ` Dave Kleikamp
  2004-03-24 18:59   ` Andreas Theofilu
  0 siblings, 1 reply; 3+ messages in thread
From: Dave Kleikamp @ 2004-03-24 13:45 UTC (permalink / raw)
  To: Andreas Theofilu; +Cc: linux-kernel, JFS Discussion

On Tue, 2004-03-23 at 12:55, Andreas Theofilu wrote:
> Hi to all,
> 
> Since kernel 2.6.4 I'm not able to access files with a special character
> in the file name, such as the german umlaute. Every attempt to access such
> a file gives me the error: cannot stat file

I did this to you.  I changed jfs's default character translation
behavior.  jfs stores the file names in ucs-16.  It had used the
character set defined by CONFIG_NLS_DEFAULT to determine how to
translate to or from ucs-16.  This can be overridden with the iocharset=
mount option.

After many complaints about characters that were being rejected by jfs,
and after getting as much feedback as I was able to obtain, I changed
the default behavior so that no translation is done.  Each byte of the
file name is now stored in the lower byte of the ucs-16 character. 
(This is equivalent to iocharset=iso8859-1, which is the default value
of CONFIG_NLS_DEFAULT.)

Unfortunately, existing files with a non-zero high byte in a character
are no longer accessible.  jfs should have printed a syslog message
recommending that the file system be mounted with iocharset=utf8 to
access the file.

> I'm using several partitions with JFS file system and had never seen such
> a strange behavior before. The relevant kernel settings are at the bottom
> of the mail.
> 
> I already unmounted the partition and run fsck on it (fsck.jfs -f
> /dev/hda8), but it told me that everything is ok and I'm still not able to
> access this files. Also a reboot of the machine didn't change anything. I
> booted 2.6.3 again and renamed the files in question (no more special
> characters in the file name). Now I can access these files with 2.6.4
> also.

Another alternative would have been to mount the filesystem with "-o
iocharset=<charset>" where <charset> is the value of
CONFIG_NLS_DEFAULT.  To make that behavior permanent, you can add the
iocharset= flag to /etc/fstab.

> Although I'm a programmer, I'm not a kernel hacker and don't know where
> to start looking for this problem. Could anybody give me a hint where to
> start looking?

I'm sorry this caused you problems.  I knew making this change would
cause some confusion, but I think in the long run, jfs is better off
with a more predictable default behavior.

-- 
David Kleikamp
IBM Linux Technology Center


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: kernel 2.6.4: Bug in JFS file system?
  2004-03-24 13:45 ` Dave Kleikamp
@ 2004-03-24 18:59   ` Andreas Theofilu
  0 siblings, 0 replies; 3+ messages in thread
From: Andreas Theofilu @ 2004-03-24 18:59 UTC (permalink / raw)
  To: Dave Kleikamp; +Cc: linux-kernel, jfs-discussion

On Wed, 24 Mar 2004 07:45:17 -0600
Dave Kleikamp <shaggy@austin.ibm.com> wrote:

> Unfortunately, existing files with a non-zero high byte in a character
> are no longer accessible.  jfs should have printed a syslog message
> recommending that the file system be mounted with iocharset=utf8 to
> access the file.
> 
Thanks for that information. I didn't found any syslog message, but
mounting the partition with iocharset=utf8 brought back the previous
unaccessible files.Now everything is working fine again.

-- 
Andreas Theofilu
http://www.TheosSoft.net/

                     --==| Enjoy the science of Linux! |==--

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2004-03-24 18:59 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-03-23 18:55 kernel 2.6.4: Bug in JFS file system? Andreas Theofilu
2004-03-24 13:45 ` Dave Kleikamp
2004-03-24 18:59   ` Andreas Theofilu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).