Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*XFS\s+and\s+write\s+barriers\.\s*$/: 42 ]

Total 42 documents matching your query.

1. XFS and write barriers. (score: 1)
Author: Neil Brown <neilb@xxxxxxx>
Date: Fri, 23 Mar 2007 12:26:31 +1100
I have two concerns related to XFS and write barrier support that I'm hoping can be resolved. Firstly in xfs_mountfs_check_barriers in fs/xfs/linux-2.6/xfs_super.c, it tests ....->queue->ordered to
/archives/xfs/2007-03/msg00157.html (8,762 bytes)

2. Re: XFS and write barriers. (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Fri, 23 Mar 2007 16:30:43 +1100
Except that the device behaviour determines what XFS needs to do and there used to be no other way to find out. Christoph, any reason for needing this check anymore? I can't see any particular reason
/archives/xfs/2007-03/msg00158.html (14,479 bytes)

3. Re: XFS and write barriers. (score: 1)
Author: Timothy Shimmin <tes@xxxxxxx>
Date: Fri, 23 Mar 2007 17:20:40 +1100
Hi Neil, --On 23 March 2007 12:26:31 PM +1100 Neil Brown <neilb@xxxxxxx> wrote: Hi, I have two concerns related to XFS and write barrier support that I'm hoping can be resolved. 1. Firstly in xfs_mou
/archives/xfs/2007-03/msg00159.html (12,202 bytes)

4. Re: XFS and write barriers. (score: 1)
Author: Neil Brown <neilb@xxxxxxx>
Date: Fri, 23 Mar 2007 18:49:50 +1100
Probably when md/raid1 started supported barriers.... The problem is that this interface is (as far as I can see) undocumented and not fully specified. Barriers only make sense inside drive firmware.
/archives/xfs/2007-03/msg00160.html (10,825 bytes)

5. Re: XFS and write barriers. (score: 1)
Author: Neil Brown <neilb@xxxxxxx>
Date: Fri, 23 Mar 2007 19:00:46 +1100
Why no barriers on an external log device??? Not important, just curious. Uhmm.. I think I just got confused reading xfs_barrier_test, I cannot see it anymore (I think I didn't see the error return a
/archives/xfs/2007-03/msg00161.html (11,575 bytes)

6. Re: XFS and write barriers. (score: 1)
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Fri, 23 Mar 2007 09:50:55 +0000
When I first implemented it I really dislike the idea of having request fail asynchrnously due to the lack of barriers. Then someone (Jens?) told me we need to do this check anyway because devices mi
/archives/xfs/2007-03/msg00163.html (12,716 bytes)

7. Re: XFS and write barriers. (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Sun, 25 Mar 2007 14:19:27 +1100
because we need to synchronize across 2 devices, not one, so issuing barriers on an external log device does nothing to order the metadata written to the other device... And this is exactly why I thi
/archives/xfs/2007-03/msg00167.html (11,189 bytes)

8. Re: XFS and write barriers. (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Sun, 25 Mar 2007 14:51:26 +1100
Ditto. You're not the only one, Christoph. This may be better than trying to handle it at lower layers, and far better than having to handle it at every point in the higher layers where we may issue
/archives/xfs/2007-03/msg00169.html (13,823 bytes)

9. Re: XFS and write barriers. (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Sun, 25 Mar 2007 15:17:55 +1100
And not communicated very far, either. I disagree. e.g. Barriers have to be handled by the block layer to prevent reordering of I/O in the request queues as well. The block layer is responsible for e
/archives/xfs/2007-03/msg00170.html (12,580 bytes)

10. Re: XFS and write barriers. (score: 1)
Author: Neil Brown <neilb@xxxxxxx>
Date: Mon, 26 Mar 2007 09:21:43 +1000
Absolutely. The block layer needs to understand about barriers and allow them to do their job, which means not re-ordering requests around barriers. My point was that if the functionality cannot be p
/archives/xfs/2007-03/msg00173.html (13,492 bytes)

11. Re: XFS and write barriers. (score: 1)
Author: Neil Brown <neilb@xxxxxxx>
Date: Mon, 26 Mar 2007 09:58:22 +1000
What would be the point of that interface? If it only says "It might be worth testing", then you still have to test. And if you have to test, where is the value in asking in advance. The is no import
/archives/xfs/2007-03/msg00174.html (11,978 bytes)

12. Re: XFS and write barriers. (score: 1)
Author: Neil Brown <neilb@xxxxxxx>
Date: Mon, 26 Mar 2007 10:01:01 +1000
Right, of course. Just like over a raid0. So you must have code to wait for all writes to the main device before writing the commit block on the journal. How hard is it to fall-back to that if the ba
/archives/xfs/2007-03/msg00175.html (9,421 bytes)

13. Re: XFS and write barriers. (score: 1)
Author: Neil Brown <neilb@xxxxxxx>
Date: Mon, 26 Mar 2007 11:11:11 +1000
But would you have multiple bios for a write that had BIO_RW_BARRIER set? That would seem .... odd. NeilBrown
/archives/xfs/2007-03/msg00176.html (9,228 bytes)

14. Re: XFS and write barriers. (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Mon, 26 Mar 2007 14:14:07 +1100
Hold on - you've said that the barrier support in a block deivce can change because of MD doing hot swap. Now you're saying there is no barrier implementation in md. Can you explain *exactly* what ba
/archives/xfs/2007-03/msg00177.html (13,960 bytes)

15. Re: XFS and write barriers. (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Mon, 26 Mar 2007 14:58:03 +1100
Forget about what you know about journalling from ext3, XFS is vastly different and much more complex..... ;) We wait for space in the log to become available during transaction reservation; we don't
/archives/xfs/2007-03/msg00178.html (10,824 bytes)

16. Re: XFS and write barriers. (score: 1)
Author: Neil Brown <neilb@xxxxxxx>
Date: Mon, 26 Mar 2007 14:27:24 +1000
For all levels other than md/raid1, md rejects bio_barrier() requests as -EOPNOTSUPP. So md/raid1 barrier support is completely dependant on the underlying devices. md/raid1 is aware of barriers but
/archives/xfs/2007-03/msg00179.html (14,768 bytes)

17. Re: XFS and write barriers. (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Mon, 26 Mar 2007 20:04:56 +1100
Ah, that clears up the picture - thanks Neil. But on a non-cached disk we've had an to have received an I/O completion before the tail of the log moves, and hence the metadata is on stable storage. T
/archives/xfs/2007-03/msg00180.html (17,569 bytes)

18. Re: XFS and write barriers. (score: 1)
Author: Timothy Shimmin <tes@xxxxxxx>
Date: Tue, 27 Mar 2007 14:58:06 +1100
here. Why no barriers on an external log device??? Not important, just curious. because we need to synchronize across 2 devices, not one, so issuing barriers on an external log device does nothing to
/archives/xfs/2007-03/msg00186.html (10,960 bytes)

19. Re: XFS and write barriers. (score: 1)
Author: Martin Steigerwald <Martin@xxxxxxxxxxxx>
Date: Thu, 29 Mar 2007 16:56:21 +0200
Am Montag 26 März 2007 schrieb David Chinner: Hello David! Just a thought, maybe it shouldn't do that automatically, but require the sysadmin to explicitely state "-o nobarrier" in that case. Safes
/archives/xfs/2007-03/msg00201.html (10,369 bytes)

20. Re: XFS and write barriers. (score: 1)
Author: David Chinner <dgc@xxxxxxx>
Date: Fri, 30 Mar 2007 02:18:58 +1100
And prevent most existing XFS filesystems from mounting after a kernel upgrade? Think about the problems that might cause with XFs root filesystems on hardware/software that doesn't support barriers.
/archives/xfs/2007-03/msg00204.html (10,641 bytes)

Current List: 1 - 20
Page: [1] [2] [3]
This search system is powered by Namazu