Re: [linux 2.6 patch] ext2 support for hurd extensions via xattr interface

[Michael Banck]

On Thu, Feb 26, 2004 at 07:55:25PM -0500, Roland McGrath wrote:
> > Just curious, would it not make sense to have this for ext3, too? After
> > all, one can mount ext3 filesystems as ext2 on GNU/Hurd (AFAIK), 
> 
> As I understand it, it is true that an ext3 filesystem with its journal
> files fully replayed or whatnot that constitutes "fully clean" state, is a
> valid ext2 filesystem.  So to that extent, yes.  However, note that this
> code is specifically for ext2 filesystems with "creator os" set to "hurd".

For the record, it is possible to create an ext3 file system with '-o
hurd', mount it as ext2 and then benefit from CONFIG_EXT2_FS_XATTR_HURD.

> > I tried using star, but I get errors when I try to extract /gnu/servers.
> > I am not sure whether this is expected to work at all, though, as I get
> > EOPNOTSUPP.
> 
> Did you compile with CONFIG_EXT2_FS_XATTR_HURD=y?
> Is the filesystem in question an ext2 filesystem with creator `hurd'?
> If you created it on GNU/Linux and didn't use `mke2fs -o hurd', then the
> answer is no.

Uhm, d'oh. I haven't read your original post for a while and somehow
assumed your patch would make '-o hurd' unimportant. Mea culpa.

As I said above, I created an ext3fs with -o hurd, mounted it as ext2
and extracted the servers/ tarball. This seems to go well, no errors
are reported by star.

However, there are three types of issues: 

1.) Quite often (seemingly random) a bogus gnu.author gets displayed by
getfattr:

blackbird/mnt$ getfattr -Rh -d -m '.*' gnu/servers
# file: gnu/servers/socket
gnu.author=0shgAAAA==

# file: gnu/servers/socket/1
gnu.translator="/hurd/pflocal\000"
[...]

That does not happen all the time, and different files get affected. It
also happened when I extracted servers/ somewhere on my /gnu-partition.

2.) Sometimes, I/O errors get reported. They seem to be coupled to star,
as every invocation of getfattr yields the same error for a set of
extracted translators.

blackbird/mnt$ getfattr -Rh -d -m '.*' gnu1/servers
# file: gnu1/servers
gnu.author=0sAQAAAA==
gnu.translator

# file: gnu1/servers/socket
gnu.author=0sAwQHCA==
gnu1/servers/socket: gnu.translator: Input/output error

# file: gnu1/servers/socket/1
gnu.author="defa"
gnu1/servers/socket/1: gnu.translator: Input/output error
[...]

Such an I/O error gets marked in the syslog as
Feb 27 21:51:17 blackbird kernel: hda5: rw=0, want=2061425788, limit=196497
Feb 27 21:51:48 blackbird kernel: attempt to access beyond end of device

(sometimes, just one or two I/O errors occur. Sometimes, all of the
files yield them)

3.) With enough patience (well, it only took a couple of attempts,
really), I got star hanging (i.e. kill -9 does not work), and trying an
getfattr on the already extracted files from a new shell also got that
hanging.

This is from syslog:

Feb 27 12:00:56 blackbird kernel: buffer layer error at fs/buffer.c:430
Feb 27 12:00:56 blackbird kernel: Call Trace:
Feb 27 12:00:56 blackbird kernel:  [__find_get_block_slow+176/352] 
__find_get_block_slow+0xb0/0x160
Feb 27 12:00:56 blackbird kernel:  [__find_get_block+161/272] 
__find_get_block+0xa1/0x110
Feb 27 12:00:56 blackbird kernel:  [__getblk_slow+56/272] 
__getblk_slow+0x38/0x110
Feb 27 12:00:56 blackbird kernel:  [__getblk+99/112] __getblk+0x63/0x70
Feb 27 12:00:56 blackbird kernel:  [__crc_in_egroup_p+425985/1634005] 
compat_hurd_set+0x1d6/0x310 [ext2]
Feb 27 12:00:56 blackbird kernel:  [try_to_wake_up+169/352] 
try_to_wake_up+0xa9/0x160
Feb 27 12:00:56 blackbird kernel:  [__crc_in_egroup_p+426874/1634005] 
ext2_xattr_hurd_set+0x11f/0x141 [ext2]
Feb 27 12:00:56 blackbird kernel:  [__crc_in_egroup_p+413147/1634005] 
ext2_setxattr+0x0/0x70 [ext2]
Feb 27 12:00:56 blackbird kernel:  [__crc_in_egroup_p+413238/1634005] 
ext2_setxattr+0x5b/0x70 [ext2]
Feb 27 12:00:56 blackbird kernel:  [setxattr+389/496] setxattr+0x185/0x1f0
Feb 27 12:00:56 blackbird kernel:  [dput+49/544] dput+0x31/0x220
Feb 27 12:00:56 blackbird kernel:  [dput+49/544] dput+0x31/0x220
Feb 27 12:00:56 blackbird kernel:  [link_path_walk+1534/2304] 
link_path_walk+0x5fe/0x900
Feb 27 12:00:56 blackbird kernel:  [__user_walk+92/96] __user_walk+0x5c/0x60
Feb 27 12:00:56 blackbird kernel:  [sys_setxattr+95/112] sys_setxattr+0x5f/0x70
Feb 27 12:00:56 blackbird kernel:  [syscall_call+7/11] syscall_call+0x7/0xb
Feb 27 12:00:56 blackbird kernel: 
Feb 27 12:00:56 blackbird kernel: block=3221224218, 
b_blocknr=18446744072635808536
Feb 27 12:00:56 blackbird kernel: b_state=0x00000010, b_size=1024

While the call trace was written about a dozen times, the last two lines were
repeated until /var was full.

I hope this information is somewhat useful, just tell me what I should
do else.


cheers,

Michael