On Tue, May 29, 2007 at 05:01:24PM -0700, [EMAIL PROTECTED] wrote:
On Wed, 30 May 2007, David Chinner wrote:
On Tue, May 29, 2007 at 04:03:43PM -0400, Phillip Susi wrote:
David Chinner wrote:
The use of barriers in XFS assumes the commit write to be on stable
storage before it returns. One
The order that these are expected by the filesystem to hit stable
storage are:
1. block 4 and 10 on stable storage in any order
2. barrier block X on stable storage
3. block 5 and 20 on stable storage in any order
The point I'm trying to make is that in XFS, block 5 and 20 cannot
be allowed to
in-flight I/O to go to zero?
Something like that is needed for some dm targets to support barriers.
(We needn't always wait for *all* in-flight I/O.)
When faced with -EOPNOTSUP, do all callers fall back to a sync in
the places a barrier would have been used, or are there any more
sophisticated
On Mon, May 28 2007, Neil Brown wrote:
I think the implementation priorities here are:
1/ implement a zero-length BIO_RW_BARRIER option.
2/ Use it (or otherwise) to make all dm and md modules handle
barriers (and loop?).
3/ Devise and implement appropriate fall-backs with-in the block
Neil,
On Tuesday, 29. May 2007, you wrote:
cc1: warnings being treated as errors
sysfs.c: In function 'sysfs_read':
sysfs.c:97: warning: value computed is not used
sysfs.c:119: warning: value computed is not used
sysfs.c:127: warning: value computed is not used
sysfs.c:133: warning:
Hi,
the following command strangely gives -EIO ...
12:27 sun:~ # mdadm -C /dev/md4 -l 1 -n 2 -e 1.0 -b internal /dev/ram0
missing
md: md4: raid array is not clean -- starting background reconstruction
md4: failed to create bitmap (-5)
md: pers-run() failed ...
mdadm: RUN_ARRAY failed:
On Wed, May 30, 2007 at 11:12:37AM +0200, Stefan Bader wrote:
it might be better to indicate -EOPNOTSUPP right from
device-mapper.
Indeed we should. For support, on receipt of a barrier, dm core should
send a zero-length barrier to all active underlying paths, and delay
mapping any further
Asking again..
On Sat, 26 May 2007, Justin Piszcz wrote:
Kernel 2.6.21.3
Fri May 25 20:00:02 EDT 2007: Executing RAID health check for /dev/md0...
Fri May 25 20:00:03 EDT 2007: Executing RAID health check for /dev/md1...
Fri May 25 20:00:04 EDT 2007: Executing RAID health check for
On May 30 2007 22:05, Neil Brown wrote:
the following command strangely gives -EIO ...
12:27 sun:~ # mdadm -C /dev/md4 -l 1 -n 2 -e 1.0 -b internal /dev/ram0
missing
md: md4: raid array is not clean -- starting background reconstruction
md4: failed to create bitmap (-5)
md: pers-run()
David Chinner wrote:
Barrier != synchronous write,
Of course. FYI, XFS only issues barriers on *async* writes.
But barrier semantics - as far as they've been described by everyone
but you indicate that the barrier write is guaranteed to be on stable
storage when it returns.
Hrm... I may
On Wed, 30 May 2007, David Chinner wrote:
On Tue, May 29, 2007 at 05:01:24PM -0700, [EMAIL PROTECTED] wrote:
On Wed, 30 May 2007, David Chinner wrote:
On Tue, May 29, 2007 at 04:03:43PM -0400, Phillip Susi wrote:
David Chinner wrote:
The use of barriers in XFS assumes the commit write to
On 29 May 2007, Jan Engelhardt uttered the following:
from your post at
http://www.mail-archive.com/linux-raid@vger.kernel.org/msg07384.html I
read that autodetecting arrays with a 1.x superblock is currently
impossible. Does it at least work to force the kernel to always assume a
1.x
Phillip Susi wrote:
Hrm... I may have misunderstood the perspective you were talking from.
Yes, when the bio is completed it must be on the media, but the
filesystem should issue both requests, and then really not care when
they complete. That is to say, the filesystem should not wait for
I'm not sure this is the right place, or that there IS a right pace for
this, but it involves RAID, so... ;-)
I have an array I mount with cryptoloop, to hole some information with
AES encryption. I keep hearing that the way to do this is with dm-crypt,
but I can't find anyone who will
Nix wrote:
On 29 May 2007, Jan Engelhardt uttered the following:
from your post at
http://www.mail-archive.com/linux-raid@vger.kernel.org/msg07384.html I
read that autodetecting arrays with a 1.x superblock is currently
impossible. Does it at least work to force the kernel to always
On May 30 2007 16:35, Bill Davidsen wrote:
On 29 May 2007, Jan Engelhardt uttered the following:
from your post at
http://www.mail-archive.com/linux-raid@vger.kernel.org/msg07384.html I
read that autodetecting arrays with a 1.x superblock is currently
impossible. Does it at least work to
On 30 May 2007, Bill Davidsen stated:
Nix wrote:
On 29 May 2007, Jan Engelhardt uttered the following:
from your post at
http://www.mail-archive.com/linux-raid@vger.kernel.org/msg07384.html I read
that autodetecting arrays with a
1.x superblock is currently impossible. Does it at least
On Wednesday May 30, [EMAIL PROTECTED] wrote:
On May 30 2007 22:05, Neil Brown wrote:
the following command strangely gives -EIO ...
12:27 sun:~ # mdadm -C /dev/md4 -l 1 -n 2 -e 1.0 -b internal /dev/ram0
missing
md: md4: raid array is not clean -- starting background
On Wed, May 30, 2007 at 09:52:49AM -0700, [EMAIL PROTECTED] wrote:
On Wed, 30 May 2007, David Chinner wrote:
with the barrier is on stable storage when I/o completion is
signalled. The existing barrier implementation (where it works)
provide these requirements. We need barriers to retain
On Tuesday May 29, [EMAIL PROTECTED] wrote:
Neil Brown wrote:
md/dm modules could keep count of requests as has been suggested
(though that would be a fairly big change for raid0 as it currently
doesn't know when a request completes - bi_endio goes directly to the
filesystem).
Are
On Monday May 28, [EMAIL PROTECTED] wrote:
There are two things I'm not sure you covered.
First, disks which don't support flush but do have a cache dirty
status bit you can poll at times like shutdown. If there are no drivers
which support these, it can be ignored.
There are really
On Monday May 28, [EMAIL PROTECTED] wrote:
On Mon, May 28, 2007 at 12:57:53PM +1000, Neil Brown wrote:
What exactly do you want to know, and why do you care?
If someone explicitly mounts -o barrier and the underlying device
cannot do it, then we want to issue a warning or reject the
mount.
On Thu, May 31, 2007 at 10:46:04AM +1000, Neil Brown wrote:
What if the truth changes (as can happen with md or dm)?
You get notified in endio() that the barrier had to be emulated?
Alasdair
--
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-raid in
the body
On Thu, May 31, 2007 at 10:46:04AM +1000, Neil Brown wrote:
If a filesystem cares, it could 'ask' as suggested above.
What would be a good interface for asking?
XFS already tests:
bd_disk-queue-ordered == QUEUE_ORDERED_NONE
Alasdair
--
[EMAIL PROTECTED]
-
To unsubscribe from this list: send
On Thu, May 31, 2007 at 02:07:39AM +0100, Alasdair G Kergon wrote:
On Thu, May 31, 2007 at 10:46:04AM +1000, Neil Brown wrote:
If a filesystem cares, it could 'ask' as suggested above.
What would be a good interface for asking?
XFS already tests:
bd_disk-queue-ordered ==
I assembled a 3-component raid1 out of 3 4GB partitions.
After syncing, I ran the following script:
for bs in 32 64 128 192 256 384 512 768 1024 ; do \
let COUNT=2048 * 1024 / ${bs}; \
echo -n ${bs}K bs - ; \
dd if=/dev/md1 of=/dev/null bs=${bs}k count=$COUNT iflag=direct 21 |
grep 'copied'
Alberto Alonso writes:
OK, lets see if I can understand how a disk gets flagged
as bad and removed from an array. I was under the impression
that any read or write operation failure flags the drive as
bad and it gets removed automatically from the array.
However, as I indicated in a prior
Jon Nelson wrote:
I am getting 70-80MB/s read rates as reported via dstat, and 60-80MB/s
as reported by dd. What I don't understand is why just one disk is being
used here, instead of two or more. I tried different versions of
metadata, and using a bitmap makes no difference. I created the
On Wed, 2007-05-30 at 22:28 -0400, Mike Accetta wrote:
Alberto Alonso writes:
OK, lets see if I can understand how a disk gets flagged
as bad and removed from an array. I was under the impression
that any read or write operation failure flags the drive as
bad and it gets removed
On Thu, 31 May 2007, Richard Scobie wrote:
Jon Nelson wrote:
I am getting 70-80MB/s read rates as reported via dstat, and 60-80MB/s as
reported by dd. What I don't understand is why just one disk is being used
here, instead of two or more. I tried different versions of metadata, and
On Monday May 28, [EMAIL PROTECTED] wrote:
Neil Brown writes:
[...]
Thus the general sequence might be:
a/ issue all preceding writes.
b/ issue the commit write with BIO_RW_BARRIER
c/ wait for the commit to complete.
If it was successful - done.
On May 31 2007 09:09, Neil Brown wrote:
the following command strangely gives -EIO ...
12:27 sun:~ # mdadm -C /dev/md4 -l 1 -n 2 -e 1.0 -b internal /dev/ram0
missing
Where could I start looking?
Linux sun 2.6.21-1.3149.al3.8smp #3 SMP Wed May 30 09:43:00 CEST 2007
sparc64 sparc64
On Wednesday May 30, [EMAIL PROTECTED] wrote:
Neil, I sent the scripts to you. Any update on this issue?
Sorry, I got distracted.
Your scripts are way more complicated than needed. Most of the logic
in there is already in mdadm.
mdadm --assemble /dev/md_d0 --run --uuid=$BOOTUUID
33 matches
Mail list logo
