Re: Kernel loop(..?) regression (& with/2.6.31-rc6)

From: Justin Piszcz
Date: Fri Aug 28 2009 - 07:23:19 EST

On Wed, 26 Aug 2009, Justin Piszcz wrote:

On Wed, 26 Aug 2009, Christoph Hellwig wrote:

On Wed, Aug 26, 2009 at 05:19:11PM -0400, Justin Piszcz wrote:
For the root filesystem, on / type xfs (rw,noatime)
For larger partitions (per the cryptoloop doc) the partition itself is
setup via cryptoloop and then XFS ontop of that. Nothing special.

Just to make sure we have all data here - you see the problem only
with loop devices backed by XFS, only with loop devices backed by
raw partitions or with both?

Any way to trgiger it with just loop but not crypto, etc.
Unfortunately not that I am aware of.. Would trying the kernel with the
patch removed and mounted with -o nobarrier help to show us anything, or?

Actually, yes - seeing what happens if you run plain 2.6.30 or 2.6.31-rc
without the backout patch, but with -o nobarrier would be very

Will give it a try with 2.6.31-rc6 and mount all loop devices (both those backed by XFS and raw partitions) with -o nobarrier to see if the problem recurs. So far though with that patch up until this next test, there were no problems.



So far:

$ uptime
07:20:04 up 1 day, 13:49, 1 user, load average: 0.07, 0.02, 0.06

Let's give it another 48-72 hours with -o nobarrier, so far, it has not recurred.

It still may happen; however, moving forward I was wondering..

If both '-o nobarrier' and the patch solves the issue, what is the next action that should be taken? Update the documentation to always use
-o nobarrier for cryptoloop? Or get the patch reverted in mainline?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at