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

[Roland McGrath]

Firstly, you are using the second patch I posted, not the first, right?

> 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.

If you want a useful record, then try it and record the results.  Off hand,
I would suspect it works, but I haven't bothered to check the details.

> 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.

Well, there you go then.

> 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==

Is it really random?  getfattr is showing you base64-encoding for that
value since it doesn't know what else to do and it's not mostly printable
characters like the translator string.  The leading 0s tells you this (see
man getfattr).  You can also use -c hex to make it show the value in hex
instead.  Anyway, hgAAAA== in base64 is little-endian 134.  Is that a uid
you might be using?

> 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.
[...]
> 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

That sure looks like a bug in my code.  Please use strace on star to
ascertain the sequence of *xattr calls and other operations on those files
that results in this lossage.  Then try to make a simple script using just
the *fattr commands and the necessary simple file commands to elicit the bug.

Your output here tells us that getxattr tried to read this bogus block
number, presumably because that bogus value was recorded as the translator
block.  

> Feb 27 12:00:56 blackbird kernel: buffer layer error at fs/buffer.c:430
[...]
> 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

I believe this is just more fallout from the attempt to read a bogus block
number previously.  Does the bogus number 3221224218 appear in other errors?

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

After you have any such errors, unmount the filesystem (or reboot if you
are screwed, whatever).  Then run e2fsck on the disk (make sure this
doesn't happen automatically at boot from /etc/fstab).  First use e2fsck -n 
and save the output to post here.  Then use e2fsck -p or e2fsck -y to
repair things so the filesystem is fully kosher before mounting it again.


Thanks,
Roland