Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*The\s+XFS\s+real\-time\s+subvolume\s+in\s+Linux\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*The\s+XFS\s+real\-time\s+subvolume\s+in\s+Linux\s*$/: 36 ]

Total 36 documents matching your query.

1. The XFS real-time subvolume in Linux (score: 1): Author: "Dubravko Markic" <dmarkic@xxxxxxxxxxx>; Date: Tue, 04 Oct 2005 12:57:28 +0200; My name is Dubravko Markic and i am working with the XFS filesystem as part of my project. I am using a Linux operating system, or better yet, a SuSe CORE 9 system. I have installed XFS filesystem o; /archives/xfs/2005-10/msg00011.html (8,307 bytes)
2. Re: The XFS real-time subvolume in Linux (score: 1): Author: Eric Sandeen <sandeen@xxxxxxx>; Date: Tue, 04 Oct 2005 09:59:31 -0500; My name is Dubravko Markic and i am working with the XFS filesystem as part of my project. I am using a Linux operating system, or better yet, a SuSe CORE 9 system. I have installed XFS filesystem on; /archives/xfs/2005-10/msg00012.html (9,956 bytes)
3. Re: The XFS real-time subvolume in Linux (score: 1): Author: Andi Kleen <ak@xxxxxxx>; Date: 04 Oct 2005 17:18:41 +0200; It's not. In fact it's a standard feature now. The CFQ2 IO scheduler has IO priorities settable with ionice, including a RT class with 8 priorities. It's not available in SLES9 though, only in newer; /archives/xfs/2005-10/msg00013.html (9,128 bytes)
4. Re: The XFS real-time subvolume in Linux (score: 1): Author: Eric Sandeen <sandeen@xxxxxxx>; Date: Tue, 04 Oct 2005 10:39:46 -0500; Andi Kleen wrote: Eric Sandeen <sandeen@xxxxxxx> writes: That is basically true, yes. There is a non-free GRIOV2 product in use with CXFS, but for your purposes, I think it is safe to say that there; /archives/xfs/2005-10/msg00014.html (10,542 bytes)
5. Re: The XFS real-time subvolume in Linux (score: 1): Author: Steve Lord <lord@xxxxxxx>; Date: Tue, 04 Oct 2005 10:41:31 -0500; Andi Kleen wrote: Eric Sandeen <sandeen@xxxxxxx> writes: That is basically true, yes. There is a non-free GRIOV2 product in use with CXFS, but for your purposes, I think it is safe to say that there; /archives/xfs/2005-10/msg00015.html (10,211 bytes)
6. Re: The XFS real-time subvolume in Linux (score: 1): Author: Andi Kleen <ak@xxxxxxx>; Date: Tue, 4 Oct 2005 17:59:14 +0200; Indirectly there is. The RT priority defines how many time slots you get and the length of the timeslots are configurable using sysfs. If you know the bandwidth of the disk you can use that to define; /archives/xfs/2005-10/msg00016.html (10,832 bytes)
7. Re: The XFS real-time subvolume in Linux (score: 1): Author: Steve Lord <lord@xxxxxxx>; Date: Tue, 04 Oct 2005 11:16:19 -0500; Andi Kleen wrote: On Tuesday 04 October 2005 17:41, Steve Lord wrote: Andi Kleen wrote: Eric Sandeen <sandeen@xxxxxxx> writes: That is basically true, yes. There is a non-free GRIOV2 product in use w; /archives/xfs/2005-10/msg00017.html (12,452 bytes)
8. Re: The XFS real-time subvolume in Linux (score: 1): Author: Jens Axboe <axboe@xxxxxxx>; Date: Wed, 5 Oct 2005 10:41:18 +0200; That's exactly why the Linux ioprio stuff has been designed the way it is right now - it's not overengineered for something we cannot support anyways. The CFQ io priorities will work well enough for; /archives/xfs/2005-10/msg00022.html (12,644 bytes)
9. Re: The XFS real-time subvolume in Linux (score: 1): Author: Jens Axboe <axboe@xxxxxxx>; Date: Wed, 5 Oct 2005 16:13:41 +0200; Oh I agree, was mainly trying to clarify that they pertain to two different market segments. Sorry if that wasn't clear, it's not a criticism of GRIO (I don't really know anything about SGI's GRIO).; /archives/xfs/2005-10/msg00025.html (10,781 bytes)
10. Re: The XFS real-time subvolume in Linux (score: 1): Author: Eric Sandeen <sandeen@xxxxxxx>; Date: Wed, 05 Oct 2005 09:11:10 -0500; Jens Axboe wrote: That's exactly why the Linux ioprio stuff has been designed the way it is right now - it's not overengineered for something we cannot support anyways. The CFQ io priorities will wor; /archives/xfs/2005-10/msg00026.html (10,597 bytes)
11. Re: The XFS real-time subvolume in Linux (score: 1): Author: Andi Kleen <ak@xxxxxxx>; Date: Wed, 5 Oct 2005 16:18:43 +0200; I suspect for most people they will be pretty much equivalent. -Andi; /archives/xfs/2005-10/msg00028.html (10,320 bytes)
12. Re: The XFS real-time subvolume in Linux (score: 1): Author: Jens Axboe <axboe@xxxxxxx>; Date: Wed, 5 Oct 2005 16:20:07 +0200; Indeed, only for the 'obscure' life-or-death type setups will there be a real difference. -- Jens Axboe; /archives/xfs/2005-10/msg00029.html (10,562 bytes)
13. Re: The XFS real-time subvolume in Linux (score: 1): Author: Andi Kleen <ak@xxxxxxx>; Date: Wed, 5 Oct 2005 16:24:15 +0200; Even for those you could in theory do bandwidth allocation on top of the RT classes with some tweaking of the time slices and knowing the worst case transfer rate of the HD, couldn't you? Basically i; /archives/xfs/2005-10/msg00030.html (9,632 bytes)
14. Re: The XFS real-time subvolume in Linux (score: 1): Author: Jens Axboe <axboe@xxxxxxx>; Date: Wed, 5 Oct 2005 16:58:10 +0200; There are still unknowns, the HD still being the biggest one of course. The problem is that you don't know the worst case HD performance, it might be doing all sorts of rewriting, calibration, error; /archives/xfs/2005-10/msg00031.html (10,169 bytes)
15. Re: The XFS real-time subvolume in Linux (score: 1): Author: Andi Kleen <ak@xxxxxxx>; Date: Wed, 5 Oct 2005 17:10:36 +0200; Yes, but GRIO has exactly the same problem. I assume they need custom calibration for each IO subsystem. -Andi; /archives/xfs/2005-10/msg00032.html (9,750 bytes)
16. Re: The XFS real-time subvolume in Linux (score: 1): Author: Jens Axboe <axboe@xxxxxxx>; Date: Wed, 5 Oct 2005 17:20:52 +0200; Indeed it does, and yes if they really want to provide the type of guarantees that Steve listed, then that needs a custom box with either custom or known disk firmware options. If not you cannot give; /archives/xfs/2005-10/msg00033.html (10,182 bytes)
17. Re: The XFS real-time subvolume in Linux (score: 1): Author: Steve Lord <lord@xxxxxxx>; Date: Wed, 05 Oct 2005 10:30:30 -0500; Jens Axboe wrote: On Wed, Oct 05 2005, Andi Kleen wrote: On Wednesday 05 October 2005 16:58, Jens Axboe wrote: There are still unknowns, the HD still being the biggest one of course. The problem is t; /archives/xfs/2005-10/msg00034.html (10,990 bytes)
18. Re: The XFS real-time subvolume in Linux (score: 1): Author: Jens Axboe <axboe@xxxxxxx>; Date: Wed, 5 Oct 2005 17:33:15 +0200; The spec'ing part is the last piece in the puzzle, that will only tell you what the io subsystem will typically do. It wont tell you how it behaves in boundary or error conditions. It's trivial to sa; /archives/xfs/2005-10/msg00035.html (11,261 bytes)
19. The XFS real-time subvolume in Linux (score: 1): Author: "Dubravko Markic" <dmarkic@xxxxxxxxxxx>; Date: Tue, 04 Oct 2005 12:57:28 +0200; My name is Dubravko Markic and i am working with the XFS filesystem as part of my project. I am using a Linux operating system, or better yet, a SuSe CORE 9 system. I have installed XFS filesystem o; /archives/xfs/2005-10/msg00152.html (8,307 bytes)
20. Re: The XFS real-time subvolume in Linux (score: 1): Author: Eric Sandeen <sandeen@xxxxxxx>; Date: Tue, 04 Oct 2005 09:59:31 -0500; My name is Dubravko Markic and i am working with the XFS filesystem as part of my project. I am using a Linux operating system, or better yet, a SuSe CORE 9 system. I have installed XFS filesystem on; /archives/xfs/2005-10/msg00153.html (9,956 bytes)

Current List: 1 - 20
Page: [1] [2]