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
J. Bruce Fields [EMAIL PROTECTED] wrote:
--without having tried to understand how they're actually used, these
data structures (like the pending_locks and granted_locks lists) seem to
duplicate stuff that's already kept in fs/locks.c. Is there a reason
they're required?
Yes. I need to get
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
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
Hi,
On Wed, 2007-05-30 at 05:13 +0200, Nick Piggin wrote:
On Tue, May 29, 2007 at 02:19:55PM -0700, Andrew Morton wrote:
The patch titled
fs: introduce write_begin, write_end, and perform_write aops
has been added to the -mm tree. Its filename is
On Wed, 30 May 2007 10:28:57 +1000
David Chinner [EMAIL PROTECTED] wrote:
On Tue, May 29, 2007 at 11:40:42AM -0400, Jeff Layton wrote:
After spending quite a bit of time tracking down a VFS: busy inodes
after unmount problem, it occurs to me that it would be nice to be
able to force a
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
Stefan Bader wrote:
You got a linear target that consists of two disks. One drive (a)
supports barriers and the other one (b) doesn't. Device-mapper just
maps the requests to the appropriate disk. Now the following sequence
happens:
1. block x gets mapped to drive b
2. block y (with barrier)
On Wed, May 30, 2007 at 09:35:32AM +0100, David Howells wrote:
J. Bruce Fields [EMAIL PROTECTED] wrote:
--without having tried to understand how they're actually used, these
data structures (like the pending_locks and granted_locks lists) seem to
duplicate stuff that's already kept in
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
This case is the result of a fairly long, drawn-out case. The problem
goes something like this:
1) mount a samba share using CIFS
2) start some continuous I/O on the mount (a loop that creates a
tarball on the mount and removes it seems to work)
3) shut down the samba server
4) suspend the
On Tue, May 29, 2007 at 08:24:41PM -0700, Andrew Morton wrote:
hm, I suppose that means I need to undrop git-ocfs2.patch. It has a mild
disagreeement with the fault-vs-invalidate patches which I didn't feel like
fixing.
Erf, somehow I missed that it was dropped. I guess I'll take a look...
On Wed, 30 May 2007 15:44:43 -0700
Mark Fasheh [EMAIL PROTECTED] wrote:
On Tue, May 29, 2007 at 08:24:41PM -0700, Andrew Morton wrote:
hm, I suppose that means I need to undrop git-ocfs2.patch. It has a mild
disagreeement with the fault-vs-invalidate patches which I didn't feel like
On Wed, 2007-05-30 at 10:21 +1000, David Chinner wrote:
On Fri, May 25, 2007 at 06:25:31PM +0200, Jean noel Cordenner wrote:
Hi,
This is an update of the i_version patch.
The i_version field is a 64bit counter that is set on every inode
creation and that is incremented every time the
On Tue, 2007-05-29 at 16:58 -0600, Andreas Dilger wrote:
On May 29, 2007 12:44 -0700, Mingming Cao wrote:
I am a little bit confused about the two patches.
It appears in the ext4_expand_inode_extra_isize patch by Kalpak, there a
new 64 bit i_fs_version field is added to ext4 inode
On Wednesday May 30, [EMAIL PROTECTED] wrote:
On Fri, May 25, 2007 at 06:25:31PM +0200, Jean noel Cordenner wrote:
The aim is to fulfill a NFSv4 requirement for rfc3530:
5.5. Mandatory Attributes - Definitions
Name# DataType Access Description
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 Wed, May 30, 2007 at 04:32:57PM -0700, Mingming Cao wrote:
On Wed, 2007-05-30 at 10:21 +1000, David Chinner wrote:
On Fri, May 25, 2007 at 06:25:31PM +0200, Jean noel Cordenner wrote:
Hi,
This is an update of the i_version patch.
The i_version field is a 64bit counter that is
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-fsdevel in
the
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 ==
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 Fri, 25 May 2007 22:21:56 +1000 [EMAIL PROTECTED] wrote:
These are intended to replace prepare_write and commit_write with more
flexible alternatives that are also able to avoid the buffered write
deadlock problems efficiently (which prepare_write is unable to do).
It doesn't like LTP's
On Wed, May 30, 2007 at 09:30:35PM -0700, Andrew Morton wrote:
On Fri, 25 May 2007 22:21:56 +1000 [EMAIL PROTECTED] wrote:
These are intended to replace prepare_write and commit_write with more
flexible alternatives that are also able to avoid the buffered write
deadlock problems
On Thu, 31 May 2007 06:43:27 +0200 Nick Piggin [EMAIL PROTECTED] wrote:
INFO: lockdep is turned off.
Code: 49 c0 89 44 24 0c 89 7c 24 08 89 5c 24 04 c7 04 24 ac 2a 49 c0 e8 e9
ff f7 ff e8 b4 21 f6 ff 8b 4d f0 e9 a6 fe ff ff 0f 0b eb fe 0f 0b eb fe
8d 74 26 00 0f 0b eb fe 0f 0b eb fe 90
On Wed, May 30, 2007 at 09:52:31PM -0700, Andrew Morton wrote:
On Thu, 31 May 2007 06:43:27 +0200 Nick Piggin [EMAIL PROTECTED] wrote:
INFO: lockdep is turned off.
Code: 49 c0 89 44 24 0c 89 7c 24 08 89 5c 24 04 c7 04 24 ac 2a 49 c0 e8
e9 ff f7 ff e8 b4 21 f6 ff 8b 4d f0 e9 a6 fe ff
On Thu, 31 May 2007 06:57:54 +0200 Nick Piggin [EMAIL PROTECTED] wrote:
Don't know - I shelved the patches.
Oh, that didn't last long :P
I have a heap of other stuff to get out the door. If I have to
do just two bisects then it's 4AM and I give up then I have to repull
everything and we're
On Wed, May 30, 2007 at 10:11:21PM -0700, Andrew Morton wrote:
On Thu, 31 May 2007 06:57:54 +0200 Nick Piggin [EMAIL PROTECTED] wrote:
Don't know - I shelved the patches.
Oh, that didn't last long :P
I have a heap of other stuff to get out the door. If I have to
do just two bisects
On Wed, May 30, 2007 at 11:39:54AM +0100, Steven Whitehouse wrote:
Hi,
On Wed, 2007-05-30 at 05:13 +0200, Nick Piggin wrote:
On Tue, May 29, 2007 at 02:19:55PM -0700, Andrew Morton wrote:
The patch titled
fs: introduce write_begin, write_end, and perform_write aops
has been
34 matches
Mail list logo
