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?
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
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
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
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?