On Mon, May 28, 2007 at 02:48:45PM +1000, Timothy Shimmin wrote:
> I'm taking it that the FUA write will just guarantee that that
> particular write has made it to disk on i/o completion
> (and no write cache flush is done).
Correct. It only applies to that one write command.
jeremy
-
To unsubsc
Back in March, Neil Brown wrote:
>
> Well it's not straight forward at all.
>
> Firstly: it can only work if all your drives are the same size
> (rounded to 64K). If they aren't raid0 will use all the available
> space on each drive, while raid5 will only use the amount that is
> available o
On Tue, 2007-05-29 at 13:28 +1000, David Chinner wrote:
> On Mon, May 28, 2007 at 05:45:27PM -0500, Alberto Alonso wrote:
> > On Fri, 2007-05-25 at 18:36 +1000, David Chinner wrote:
> > > I consider the possibility of serving out bad data (i.e after
> > > a remount to readonly) to be the worst poss
On Mon, May 28, 2007 at 05:45:27PM -0500, Alberto Alonso wrote:
> On Fri, 2007-05-25 at 18:36 +1000, David Chinner wrote:
> > On Fri, May 25, 2007 at 12:43:51AM -0500, Alberto Alonso wrote:
> > > I think his point was that going into a read only mode causes a
> > > less catastrophic situation (ie.
On Mon, May 28, 2007 at 05:30:52PM +0200, Pallai Roland wrote:
>
> On Monday 28 May 2007 14:53:55 Pallai Roland wrote:
> > On Friday 25 May 2007 02:05:47 David Chinner wrote:
> > > "-o ro,norecovery" will allow you to mount the filesystem and get any
> > > uncorrupted data off it.
> > >
> > > You
On Mon, May 28, 2007 at 01:17:31PM +0200, Pallai Roland wrote:
> On Monday 28 May 2007 04:17:18 David Chinner wrote:
> > H. A quick look at the linux code makes me thikn that background
> > writeback on linux has never been able to cause a shutdown in this case.
> > However, the same error on I
On Fri, 2007-05-25 at 18:36 +1000, David Chinner wrote:
> On Fri, May 25, 2007 at 12:43:51AM -0500, Alberto Alonso wrote:
> > I think his point was that going into a read only mode causes a
> > less catastrophic situation (ie. a web server can still serve
> > pages).
>
> Sure - but once you've det
(dunny why you explicitly dropped me off the cc/to list when replying to
my email, hence I missed it for 3 days)
On Fri, May 25 2007, Phillip Susi wrote:
> Jens Axboe wrote:
> >A barrier write will include a flush, but it may also use the FUA bit to
> >ensure data is on platter. So the only situa
tj wrote:
Thomas Jager wrote:
Hi list.
I run a file server on MD raid-5.
If a client reads one big file and at the same time another client
tries to write a file, the thread writing just sits in
uninterruptible sleep until the reader has finished. Only very small
amount of writes get trough
On Monday 28 May 2007 14:53:55 Pallai Roland wrote:
> On Friday 25 May 2007 02:05:47 David Chinner wrote:
> > "-o ro,norecovery" will allow you to mount the filesystem and get any
> > uncorrupted data off it.
> >
> > You still may get shutdowns if you trip across corrupted metadata in
> > the file
Neil Brown wrote:
We can think of there being three types of devices:
1/ SAFE. With a SAFE device, there is no write-behind cache, or if
there is it is non-volatile. Once a write completes it is
completely safe. Such a device does not require barriers
or ->iss
Tomka Gergely wrote:
Hi!
I am drawing this picture for teaching:
http://gergely.tomka.hu/kep/raidstates.png
Is this a correct picture? I am not sure in the difference between
active/clean and resync/recover.
thanks for any comment.
Looks good to me, perhaps a copyright and creative common
On Friday 25 May 2007 02:05:47 David Chinner wrote:
> "-o ro,norecovery" will allow you to mount the filesystem and get any
> uncorrupted data off it.
>
> You still may get shutdowns if you trip across corrupted metadata in
> the filesystem, though.
This filesystem is completely dead.
hq:~# mount
On Monday 28 May 2007 04:17:18 David Chinner wrote:
> On Mon, May 28, 2007 at 03:50:17AM +0200, Pallai Roland wrote:
> > On Monday 28 May 2007 02:30:11 David Chinner wrote:
> > > On Fri, May 25, 2007 at 04:35:36PM +0200, Pallai Roland wrote:
> > > > .and I've spammed such messages. This "internal
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.
> If it failed other than with EOPNOTSUPP, a
On Mon, May 28, 2007 at 11:30:32AM +1000, Neil Brown wrote:
> 1/ A BIO_RW_BARRIER request should never fail with -EOPNOTSUP.
The device-mapper position has always been that we require
> a zero-length BIO_RW_BARRIER
(i.e. containing no data to read or write - or emulated, possibly
device-speci
Hello,
Neil Brown wrote:
> 1/ A BIO_RW_BARRIER request should never fail with -EOPNOTSUP.
>
> This is certainly a very attractive position - it makes the interface
> cleaner and makes life easier for filesystems and other clients of
> the block interface.
> Currently filesystems handle -EOPNO
17 matches
Mail list logo
