Terje Fåberg wrote:
> Additionally, I verified that xfs on loop-aes on a
> plain partition works perfectly. So reproducing the
> problem requires at least xfs AND loop-aes AND (lvm
> OR raid).
I think this mystery is now solved.
XFS file system attempts to optimize I/O transfers to underlying device. It
may do variable length partial page transfers. However it also understands
that some devices get really pissed with variable length transfers (raid
devices for example), and attempts to avoid variable length transfers on
those devices.
Case #1: XFS --> PARTITION
XFS uses variable length transfers. Disk driver handles them okay.
No problems here.
Case #2: XFS --> LOOP --> PARTITION
XFS uses variable length transfers. Loop handles them okay and pass them
to underlying disk driver. Disk driver handles them okay. No problems
here.
Case #3: XFS --> RAID --> PARTITIONS
XFS detects problematic raid device and does not use variable length
transfers. Neither raid nor disk driver sees variable length transfers.
No problems here.
Case #4: XFS --> LOOP --> RAID --> PARTITIONS
XFS does not detect problematic device and uses variable length
transfers. Loop handles them ok and pass them to underlying raid driver.
Raid driver gets really pissed here.
I have included one-liner patch for XFS that teaches XFS not to send
variable length I/O requests to loop device. XFS really does not know what
kind of device is below loop device.
I still see raid code emitting those "switching cache buffer size" kernel
messages in case #4, but case #3 emits those messages too.
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
--- linux-2.4.22aa1r3/fs/xfs/linux/xfs_super.c.old Fri Dec 12 08:19:49 2003
+++ linux-2.4.22aa1r3/fs/xfs/linux/xfs_super.c Fri Dec 12 08:20:58 2003
@@ -303,6 +303,7 @@
switch (MAJOR(btp->pbr_dev)) {
case MD_MAJOR:
+ case LOOP_MAJOR:
case EVMS_MAJOR:
btp->pbr_flags = PBR_ALIGNED_ONLY;
break;
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
