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 _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
