s possible that I am incorrect. However, my understanding is that yes, you do need data-journaled quota files to ensure that your quota tables don't miss
ty much all locking is done on the VFS above the filesystem. Locking methods should therefore work with all filesystems in pretty much the same way. --cw
s was the right place. ANy way I prety sure that I found a small bug at this place. Here is my full patch: -- cmd/xfsprogs/libxfs/init.c.orig 2002-10-25 12:12:29.000000000 +0200 +++ cmd
m is somewhat repeatable, there are a couple things we can try to get more information. Although, if it's in production, maybe that's not possible? -Eric
ernel (20021022) diff versus 2.4.19 vanilla kernel, apply it against 2.4.19-pa22 (with very small problem) and obtain a bootable (and operational) kernel. Now I rebuild debian
re supported by XFS (if any)? In particular, does it support range locking? Regards, -James Goodwin Software Engineer IBM Global Services - Federal jagoodwi@xxxxxxxxxx Pho
Hi all, I build a xfs-kernel (20021022) diff versus 2.4.19 vanilla kernel, apply it against 2.4.19-pa22 (with very small problem) and obtain a bootable (and operational) kernel. Now I rebuild debian
Looks like mkfs.xfs is trying to write past the end of the device. Possibly the BLKGETSIZE64 ioctl has been mishandled by the device driver? 2199023190016 is a fairly large byte offset. This ioctl is
Hi Nathan, This was the right place. ANy way I prety sure that I found a small bug at this place. Here is my full patch: -- cmd/xfsprogs/libxfs/init.c.orig 2002-10-25 12:12:29.000000000 +0200 +++ cmd
Hi, thanks for looking into it. I originally handled the error as I did because per the ioctl man page, RETURN VALUE Usually, on success zero is returned. A few ioctls use the return value as an outp