On Fri, Jun 01 2007, Neil Brown wrote:
> On Friday June 1, [EMAIL PROTECTED] wrote:
> > On Thu, May 31, 2007 at 02:31:21PM -0400, Phillip Susi wrote:
> > > David Chinner wrote:
> > > >That sounds like a good idea - we can leave the existing
> > > >WRITE_BARRIER behaviour unchanged and introduce a n
On Friday June 1, [EMAIL PROTECTED] wrote:
> On Thu, May 31, 2007 at 02:31:21PM -0400, Phillip Susi wrote:
> > David Chinner wrote:
> > >That sounds like a good idea - we can leave the existing
> > >WRITE_BARRIER behaviour unchanged and introduce a new WRITE_ORDERED
> > >behaviour that only guarant
On Fri, 1 Jun 2007, Tejun Heo wrote:
but one
thing we should bear in mind is that harddisks don't have humongous
caches or very smart controller / instruction set. No matter how
relaxed interface the block layer provides, in the end, it just has to
issue whole-sale FLUSH CACHE on the device to
Stefan Bader wrote:
> 2007/5/30, Phillip Susi <[EMAIL PROTECTED]>:
>> Stefan Bader wrote:
>> >
>> > Since drive a supports barrier request we don't get -EOPNOTSUPP but
>> > the request with block y might get written before block x since the
>> > disk are independent. I guess the chances of this are
Jens Axboe wrote:
> On Thu, May 31 2007, David Chinner wrote:
>> On Thu, May 31, 2007 at 08:26:45AM +0200, Jens Axboe wrote:
>>> On Thu, May 31 2007, David Chinner wrote:
IOWs, there are two parts to the problem:
1 - guaranteeing I/O ordering
2 - guaranteeing blocks are on
On Thursday May 24, [EMAIL PROTECTED] wrote:
> I believe I've come across a bug in the disk read error recovery logic
> for raid1 check/repair operations in 2.6.20. The raid1.c file looks
> identical in 2.6.21 so the problem should still exist there as well.
Yes, you have found a bug, thanks.
>
On Thu, May 31, 2007 at 02:31:21PM -0400, Phillip Susi wrote:
> David Chinner wrote:
> >That sounds like a good idea - we can leave the existing
> >WRITE_BARRIER behaviour unchanged and introduce a new WRITE_ORDERED
> >behaviour that only guarantees ordering. The filesystem can then
> >choose which
On Thu, May 31 2007, [EMAIL PROTECTED] wrote:
> On Thu, 31 May 2007, Jens Axboe wrote:
>
> >On Thu, May 31 2007, Phillip Susi wrote:
> >>David Chinner wrote:
> >>>That sounds like a good idea - we can leave the existing
> >>>WRITE_BARRIER behaviour unchanged and introduce a new WRITE_ORDERED
> >>>
On Thu, 31 May 2007, Jens Axboe wrote:
On Thu, May 31 2007, Phillip Susi wrote:
David Chinner wrote:
That sounds like a good idea - we can leave the existing
WRITE_BARRIER behaviour unchanged and introduce a new WRITE_ORDERED
behaviour that only guarantees ordering. The filesystem can then
cho
Hi,
Can you tell me of someone that can help me?
I had a hard drive failure and mistakenly added a device to my
raid-5, but I should have used assemble, so now the disk that holds
data is spare and should be active.
How can I remove the 'Spare' flag from that device?
Please, please, please
On May 31 2007 09:00, Bill Davidsen wrote:
>> >
>>
>> Hardly, with all the Fedora specific cruft. Anyway, there was a
>> simple patch posted in RH bugzilla, so I've gone with that.
>>
> I'm not sure what Fedora has to do with it,
I like highly modularized systems. And that requires an initramf
On Thu, May 31 2007, Phillip Susi wrote:
> David Chinner wrote:
> >That sounds like a good idea - we can leave the existing
> >WRITE_BARRIER behaviour unchanged and introduce a new WRITE_ORDERED
> >behaviour that only guarantees ordering. The filesystem can then
> >choose which to use where appropr
On Thu, May 31 2007, Phillip Susi wrote:
> Jens Axboe wrote:
> >No Stephan is right, the barrier is both an ordering and integrity
> >constraint. If a driver completes a barrier request before that request
> >and previously submitted requests are on STABLE storage, then it
> >violates that principl
Jens Axboe wrote:
No Stephan is right, the barrier is both an ordering and integrity
constraint. If a driver completes a barrier request before that request
and previously submitted requests are on STABLE storage, then it
violates that principle. Look at the code and the various ordering
options.
David Chinner wrote:
That sounds like a good idea - we can leave the existing
WRITE_BARRIER behaviour unchanged and introduce a new WRITE_ORDERED
behaviour that only guarantees ordering. The filesystem can then
choose which to use where appropriate
So what if you want a synchronous write, b
David Chinner wrote:
you are understanding barriers to be the same as syncronous writes. (and
therefor the data is on persistant media before the call returns)
No, I'm describing the high level behaviour that is expected by
a filesystem. The reasons for this are below
You say no, but then
On Thu, May 31 2007, Bill Davidsen wrote:
> Jens Axboe wrote:
> >On Thu, May 31 2007, David Chinner wrote:
> >
> >>On Thu, May 31, 2007 at 08:26:45AM +0200, Jens Axboe wrote:
> >>
> >>>On Thu, May 31 2007, David Chinner wrote:
> >>>
> IOWs, there are two parts to the problem:
>
Jens Axboe wrote:
On Thu, May 31 2007, David Chinner wrote:
On Thu, May 31, 2007 at 08:26:45AM +0200, Jens Axboe wrote:
On Thu, May 31 2007, David Chinner wrote:
IOWs, there are two parts to the problem:
1 - guaranteeing I/O ordering
2 - guaranteeing blocks are
Jan Engelhardt wrote:
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.
Neil Brown wrote:
On Wednesday May 30, [EMAIL PROTECTED] wrote:
On Wed, 30 May 2007, Jon Nelson wrote:
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
Neil Brown wrote:
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.
2007/5/30, Phillip Susi <[EMAIL PROTECTED]>:
Stefan Bader wrote:
>
> Since drive a supports barrier request we don't get -EOPNOTSUPP but
> the request with block y might get written before block x since the
> disk are independent. I guess the chances of this are quite low since
> at some point a
Hello
I'm having problems with a RAID-1 configuration. I cannot re-add a disk
that I've failed, because each time I do this, the re-added disk is
still seen as failed.
After some investigations, I found that this problem only occur when I
create the RAID array with superblocks 1.0, 1.1 and 1.2
On Thu, May 31 2007, David Chinner wrote:
> On Thu, May 31, 2007 at 08:26:45AM +0200, Jens Axboe wrote:
> > On Thu, May 31 2007, David Chinner wrote:
> > > IOWs, there are two parts to the problem:
> > >
> > > 1 - guaranteeing I/O ordering
> > > 2 - guaranteeing blocks are on persistent storag
On Thu, May 31, 2007 at 08:26:45AM +0200, Jens Axboe wrote:
> On Thu, May 31 2007, David Chinner wrote:
> > IOWs, there are two parts to the problem:
> >
> > 1 - guaranteeing I/O ordering
> > 2 - guaranteeing blocks are on persistent storage.
> >
> > Right now, a single barrier I/O is use
25 matches
Mail list logo
