Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*raid10n2\/xfs\s+setup\s+guidance\s+on\s+write\-cache\/barrier\s*$/: 26 ]

Total 26 documents matching your query.

1. Re: raid10n2/xfs setup guidance on write-cache/barrier (score: 1)
Author: pg@xxxxxxxxxxxxxxxxxxx (Peter Grandi)
Date: Thu, 15 Mar 2012 14:07:25 +0000
Consider also an 'o2' layout (it is probably the same thing for a 3 drive RAID10) or even a RAID5, as 3 drives and this usage seems one of the few cases where RAID5 may be plausible. That's for bulk
/archives/xfs/2012-03/msg00330.html (17,697 bytes)

2. Re: raid10n2/xfs setup guidance on write-cache/barrier (score: 1)
Author: keld@xxxxxxxxxx
Date: Thu, 15 Mar 2012 16:25:48 +0100
Well, for a file server like NFS/Samba, you could also consider raid10,f2. I would think you could get about double the read performance compared to n2 and o2 layouts, and also for individual read tr
/archives/xfs/2012-03/msg00331.html (9,317 bytes)

3. Re: raid10n2/xfs setup guidance on write-cache/barrier (score: 1)
Author: Jessie Evangelista <jessie.evangelista@xxxxxxxxx>
Date: Fri, 16 Mar 2012 00:18:41 +0800
Hey Peter, Thanks for reminding me about raid5. I'll probably give it a try and do some benchmarks. I'd also like to try raid10f2. thanks for this tip. will look into adjusting inode size. it seems t
/archives/xfs/2012-03/msg00334.html (22,720 bytes)

4. Re: raid10n2/xfs setup guidance on write-cache/barrier (score: 1)
Author: Jessie Evangelista <jessie.evangelista@xxxxxxxxx>
Date: Fri, 16 Mar 2012 00:52:19 +0800
Hi keld, I also plan to try raid10f2. Did you do your own benchmarks or are you quoting someone elses? thanks for chiming in. have a nice day
/archives/xfs/2012-03/msg00336.html (10,825 bytes)

5. Re: raid10n2/xfs setup guidance on write-cache/barrier (score: 1)
Author: keld@xxxxxxxxxx
Date: Thu, 15 Mar 2012 18:15:49 +0100
Both, look at our wiki: https://raid.wiki.kernel.org/articles/p/e/r/Performance.html Best regards keld
/archives/xfs/2012-03/msg00337.html (10,291 bytes)

6. Re: raid10n2/xfs setup guidance on write-cache/barrier (score: 1)
Author: keld@xxxxxxxxxx
Date: Thu, 15 Mar 2012 18:40:08 +0100
I think it would be interesting to include your figures on the wiki page, if you publish them here on the list. Maybe we should rearrange the wiki page a little. I am not so happy about the data repo
/archives/xfs/2012-03/msg00338.html (11,562 bytes)

7. Re: raid10n2/xfs setup guidance on write-cache/barrier (score: 1)
Author: pg@xxxxxxxxxxxxxxxxxxxx (Peter Grandi)
Date: Thu, 15 Mar 2012 23:00:41 +0000
[ ... ] But usually you can still set the XFS idea of sector size to 4096, which is probably a good idea in general. [ ... ] I did that in the following bits of the reply. You must be in a real hurry
/archives/xfs/2012-03/msg00344.html (13,486 bytes)

8. Re: raid10n2/xfs setup guidance on write-cache/barrier (score: 1)
Author: Jessie Evangelista <jessie.evangelista@xxxxxxxxx>
Date: Fri, 16 Mar 2012 11:36:07 +0800
I'm now running kernel 3.0.0-16-server Ubuntu 10.04LTS cat /sys/block/sd[b-d]/queue/physical_block_size shows 512 cat /sys/block/sd[b-d]/device/model shows ST31000524AS looking up the model at seaga
/archives/xfs/2012-03/msg00346.html (15,311 bytes)

9. Re: raid10n2/xfs setup guidance on write-cache/barrier (score: 1)
Author: Michael Monnerie <michael.monnerie@xxxxxxxxxxxxxxxxxxx>
Date: Fri, 16 Mar 2012 12:06:54 +0100
Am Freitag, 16. März 2012, 11:36:07 schrieb Jessie Evangelista: If you ever experienced a crash where lots of sensible and important data were lost, you would not even think about "device cache ON".
/archives/xfs/2012-03/msg00349.html (11,003 bytes)

10. Re: raid10n2/xfs setup guidance on write-cache/barrier (score: 1)
Author: pg@xxxxxxxxxxxxxxxxxxx (Peter Grandi)
Date: Fri, 16 Mar 2012 12:21:50 +0000
[ ... ] It is not as simple as that... *If* hw barriers are implemented *and* applications do the right things, that is not a concern. Disabling the device cache is just a way to turn barriers on for
/archives/xfs/2012-03/msg00351.html (10,952 bytes)

11. Re: raid10n2/xfs setup guidance on write-cache/barrier (score: 1)
Author: Brian Candler <B.Candler@xxxxxxxxx>
Date: Fri, 16 Mar 2012 17:15:09 +0000
I would just make the raw disks members of the RAID array, e.g. /dev/sdb, /dev/sdc etc and not partition them.
/archives/xfs/2012-03/msg00355.html (11,648 bytes)

12. Re: raid10n2/xfs setup guidance on write-cache/barrier (score: 1)
Author: pg@xxxxxxxxxxxxxxxxxxx (Peter Grandi)
Date: Fri, 16 Mar 2012 19:28:24 +0000
[ ... ] Not well expressed, as XFS barriers do ensure file data integrity, *if the applications uses them* (and uses them in exactly the right way). The difference between metadata and data with XFS
/archives/xfs/2012-03/msg00362.html (13,637 bytes)

13. Re: raid10n2/xfs setup guidance on write-cache/barrier (score: 1)
Author: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
Date: Fri, 16 Mar 2012 19:02:22 -0500
Given the audience, the OP, I was simply avoiding getting too deep in the weeds Peter. This thread is on the linux-raid list, not xfs@oss. You know I have a tendency to get too deep in the weeds. I t
/archives/xfs/2012-03/msg00364.html (14,319 bytes)

14. Re: raid10n2/xfs setup guidance on write-cache/barrier (score: 1)
Author: pg@xxxxxxxxxxxxxxxxxxxx (Peter Grandi)
Date: Sat, 17 Mar 2012 15:35:06 +0000
[ ... ] As a general principle it is good, that has almost no cost. Indeed recent versions of some partitionig tools do that by default. I often recommend aligning partitions to 1GiB, also because I
/archives/xfs/2012-03/msg00367.html (13,479 bytes)

15. Re: raid10n2/xfs setup guidance on write-cache/barrier (score: 1)
Author: pg_xf2@xxxxxxxxxxxxxxxxxx (Peter Grandi)
Date: Sun, 18 Mar 2012 02:09:47 +0000
[ ... ] It is noticeable that Stan and you have chosen to write offtopic "contributions" that contain purely personal attacks in reply to a technical point about «guidance on write-cache/barrier», bu
/archives/xfs/2012-03/msg00372.html (12,658 bytes)

16. Re: raid10n2/xfs setup guidance on write-cache/barrier (score: 1)
Author: pg@xxxxxxxxxxxxxxxxxxx (Peter Grandi)
Date: Sun, 18 Mar 2012 11:25:14 +0000
I have left implicit a point that perhaps should be explicit: I think that XFS metadata performance before 'delaylog' was pretty good, and that it has remained pretty good with 'delaylog'. People wh
/archives/xfs/2012-03/msg00375.html (12,029 bytes)

17. Re: raid10n2/xfs setup guidance on write-cache/barrier (score: 1)
Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Sun, 18 Mar 2012 10:00:51 -0400
For many workloads it absolutely wasn't. No, they weren't, and as with most posts to the XFS and RAID lists you are completely off the track. Plese read through Documentation/filesystems/xfs-delayed-
/archives/xfs/2012-03/msg00376.html (11,926 bytes)

18. Re: raid10n2/xfs setup guidance on write-cache/barrier (score: 1)
Author: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
Date: Sun, 18 Mar 2012 13:08:35 -0500
You have recommended in various past posts on multiple lists that users should max out logbsize and logbufs to increase metadata performance. You made no mention in those posts about safety as you ha
/archives/xfs/2012-03/msg00378.html (12,715 bytes)

19. Re: raid10n2/xfs setup guidance on write-cache/barrier (score: 1)
Author: pg@xxxxxxxxxxxxxxxxxxx (Peter Grandi)
Date: Sun, 18 Mar 2012 19:17:16 +0000
[ ... ] My self importance is not quite as huge as feeling able to just say «absolutely wasn't» to settle points once and for all. So I would rather argue (and I did in a different form) that for som
/archives/xfs/2012-03/msg00379.html (14,222 bytes)

20. Re: raid10n2/xfs setup guidance on write-cache/barrier (score: 1)
Author: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>
Date: Mon, 19 Mar 2012 04:07:25 -0500
It is noticeable that 100% of my post was technical content, directly asked questions of you, yet you chose to respond to Christoph's "personal attacks" while avoiding answering my purely technical q
/archives/xfs/2012-03/msg00383.html (11,457 bytes)


This search system is powered by Namazu