hi Justin,
On Mon, Nov 26, 2001 at 12:58:42PM +0000, Justin Cormack wrote:
> I have been having an acl/attr related problem with xfs
>From reading your mail, this probably isn't an ACL/attr problem,
but its not clear where the problem might be yet.
> linux 2.4.9+
> patch-2.4.9-xfs-2001-08-19.bz2
>
> I am not exactly sure how it arose. I havent been using acls, and in fact my
> kernel was not compiled with acl support (and I am not sure it ever has been).
> I was happily using xfs on one partition that I use for video streaming,
> until one day I tried to write to it and the machine hung solid. No syslog
> message on the serial console, nothing at all. This behaviour was consistent.
Can you try building kdb in and getting a stack trace - using the
'bt' command - when the machine hangs (and drops into kdb)?
> It also refused to let me create directories, saying permission denied, which
Odd - this suggests a problem in XFS, or the underlying device has
been marked readonly for some reason (sometimes results in EPERM).
> is why I suspected acls, and then discovered that even doing lsattr on the
> partition would die the same way. xfs_check reported no errors, nor did the
> SMART on the drive. I recompiled the kernel with acl support,
As Utz has said, XFS ACLs and extended attributes use different
interfaces (syscalls) to the ext2 lsattr/chattr commands (ioctl).
> and now lsattr gives
> lsattr: Invalid argument While reading flags on /video/.
> ------------ /video/..
> lsattr: Invalid argument While reading flags on /video/lost+found
> lsattr: Invalid argument While reading flags on /video/left-raw
> lsattr: Invalid argument While reading flags on /video/right-raw
> ------------ /video/images
> ------------ /video/text
>
> Any idea what is going on?
>
> Please cc as not on list
>
> Justin
>
The "Invalid argument" (EINVAL) message is coming from the XFS
kernel code, because it receives a request for an ioctl which it
doesn't know anything about (an ext2 ioctl in this case).
This is arguably a buglet in e2fsprogs - in xfsprogs, wherever we
issue an XFS-specific ioctl to an arbitary file descriptor we 1st
check that it is indeed on an XFS filesystem (using fstatfs).
But its just a matter of style/taste on the e2fsprogs maintainers
part, I guess - Ted, below is a little patch which is the sort of
thing we do in the XFS utilites before we issue any XFS-specific
ioctl call. This checks the lsattr/chattr calls - there may well
be several other ioctls I've missed in other parts of the code.
cheers.
--
Nathan
diff -Naur e2fsprogs-1.25/lib/e2p/fgetflags.c
e2fsprogs-1.25-ns/lib/e2p/fgetflags.c
--- e2fsprogs-1.25/lib/e2p/fgetflags.c Thu Sep 20 11:24:12 2001
+++ e2fsprogs-1.25-ns/lib/e2p/fgetflags.c Tue Nov 27 09:43:39 2001
@@ -31,6 +31,7 @@
#endif
#include "e2p.h"
+#include <sys/statfs.h>
#ifdef O_LARGEFILE
#define OPEN_FLAGS (O_RDONLY|O_NONBLOCK|O_LARGEFILE)
@@ -64,10 +65,19 @@
#else
#if HAVE_EXT2_IOCTLS
int fd, r, f;
+ struct statfs sf;
+ extern int errno;
fd = open (name, OPEN_FLAGS);
if (fd == -1)
return -1;
+ r = fstatfs (fd, &sf);
+ if (r == -1)
+ return -1;
+ if (sf.f_type != EXT2_SUPER_MAGIC) {
+ errno = EOPNOTSUPP;
+ return -1;
+ }
r = ioctl (fd, EXT2_IOC_GETFLAGS, &f);
*flags = f;
diff -Naur e2fsprogs-1.25/lib/e2p/fsetflags.c
e2fsprogs-1.25-ns/lib/e2p/fsetflags.c
--- e2fsprogs-1.25/lib/e2p/fsetflags.c Thu Sep 20 11:24:12 2001
+++ e2fsprogs-1.25-ns/lib/e2p/fsetflags.c Tue Nov 27 09:43:47 2001
@@ -31,6 +31,7 @@
#endif
#include "e2p.h"
+#include <sys/statfs.h>
#ifdef O_LARGEFILE
#define OPEN_FLAGS (O_RDONLY|O_NONBLOCK|O_LARGEFILE)
@@ -60,10 +61,19 @@
#else
#if HAVE_EXT2_IOCTLS
int fd, r, f;
+ struct statfs sf;
+ extern int errno;
fd = open (name, OPEN_FLAGS);
if (fd == -1)
return -1;
+ r = fstatfs (fd, &sf);
+ if (r == -1)
+ return -1;
+ if (sf.f_type != EXT2_SUPER_MAGIC) {
+ errno = EOPNOTSUPP;
+ return -1;
+ }
f = (int) flags;
r = ioctl (fd, EXT2_IOC_SETFLAGS, &f);
close (fd);
|