public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Timothy Shimmin <tes@sgi.com>
To: Martin Steigerwald <Martin@lichtvoll.de>
Cc: linux-xfs@oss.sgi.com
Subject: Re: xfs FAQ update for write cache
Date: Fri, 21 Jul 2006 16:17:12 +1000	[thread overview]
Message-ID: <44C07168.60904@sgi.com> (raw)
In-Reply-To: <200607200955.36136.Martin@lichtvoll.de>

Hi Martin,

Martin Steigerwald wrote:
> Am Donnerstag 20 Juli 2006 08:02 schrieb Timothy Shimmin:
>> Modid:  current:xfs-website:212892a
>> faq.html - 1.88 - changed
>> 	- Update info about write cache.
>> 	  Mention persistent write cache, external logs,
>> 	  checking it was actually enabled in xfs msgs.
> 
> Hello Timothy,
> 
> thanks a lot... thats awesome... I have that directory corruption problem 
> also mentioned in the FAQ on a workstation at work. When you have a new 
> xfs_check available I can test it. (I know how to compile it under 
> Knoppix 5 ;-).
> 
> A little feedback: lines are not wrapped in either Firefox or Konqueror 
> (http://oss.sgi.com/projects/xfs/faq.html). This is for the complete FAQ. 
> It makes reading it difficult.
I believe Nathan has fixed this now.

> 
> It might make sense to include the log messages when barriers are disabled 
> at the approbiate places of the FAQ:
> 
Yeah, I was thinking of that - like Dave (dgc) did in his reply.
If you think that is helpful.

> root@deepdance:/usr/src/linux/fs/xfs -> grep -ir "barrier" *
> linux-2.6/xfs_super.c:xfs_mountfs_check_barriers(xfs_mount_t *mp)
> linux-2.6/xfs_super.c:            "Disabling barriers, not supported with 
> external log device");
> linux-2.6/xfs_super.c:          mp->m_flags &= ~XFS_MOUNT_BARRIER;
> linux-2.6/xfs_super.c:            "Disabling barriers, not supported by 
> the underlying device");
> linux-2.6/xfs_super.c:          mp->m_flags &= ~XFS_MOUNT_BARRIER;
> linux-2.6/xfs_super.c:  error = xfs_barrier_test(mp);
> linux-2.6/xfs_super.c:            "Disabling barriers, trial barrier write 
> failed");
> linux-2.6/xfs_super.c:          mp->m_flags &= ~XFS_MOUNT_BARRIER;
> 
> While they are quite self-explanatory it might still help to make it 
> absolutely clear what each log message mean.
Ok.

> 
> Is the last one  "Disabling barriers, trial barrier write failed" issued 
> when the underlying device does not support write barriers?

You mean is it the same as the msg:
"Disabling barriers, not supported by the underlying device" ;-)
I guess the end result is pretty much the same but the test is
different. I didn't write the code (Christoph could provide more
info here) but looking at it now...

The "trial barrier write" actually tries a barrier write on the
superblock and sees if we get an error back.

Whereas the "not supported by" case, we use the information set by
the driver for the block layer - it sets one of the ordered modes
as described in the doc you quoted Documentation/block/barrier.txt.
We test for QUEUE_ORDERED_NONE to give this message.
The doc says:
   QUEUE_ORDERED_NONE
       I/O barriers are not needed and/or supported.
Looking at IDE case, it would set ordered mode to NONE if
write cache was on and not supported by drive.
But I guess perhaps the only definitive way to be sure is to
try it out and hence the trial write.

And as for the external log case, we _may_ end up changing the
code to flush on the data device and log device and so not
need this message and action. We'll see.

Cheers,
Tim.

  reply	other threads:[~2006-07-21  6:19 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-20  6:02 xfs FAQ update for write cache Timothy Shimmin
2006-07-20  7:55 ` Martin Steigerwald
2006-07-21  6:17   ` Timothy Shimmin [this message]
2006-07-21  9:26     ` Martin Steigerwald

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44C07168.60904@sgi.com \
    --to=tes@sgi.com \
    --cc=Martin@lichtvoll.de \
    --cc=linux-xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox