Re: Source code of SGI XFS
As Mike Smith wrote ... Pavel Narozhniy wrote: Does anybody heard about SGI releasing XFS source code? Yup, they're doing it. I would guess that FreeBSD would need a fairly thorough revamp of its handling of kernel memory allocation before XFS would be fully usable, though: XFS buffer management is pretty full-on. Read Irix has shitty block I/O support so XFS has to do it all itself. The filesystem maintains its own pool of kernel buffers separate from the VM page cache which it uses for aggregating I/O transfers (so that if, say, you make 5 separate out-of-order I/Os which just happen to blanket a contiguous region of a disk object, XFS will collapse them into a single I/O; We do this too; it's called I/O clustering, but it's done below the filesystem so that anyone and everyone can benefit from it. The most interesting thing of XFS is it's GRIO I'd say. | / o / / _ Arnhem, The Netherlands- Powered by FreeBSD - |/|/ / / /( (_) BulteWWW : http://www.tcja.nl http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Source code of SGI XFS
Pavel Narozhniy wrote: Does anybody heard about SGI releasing XFS source code? Yup, they're doing it. I would guess that FreeBSD would need a fairly thorough revamp of its handling of kernel memory allocation before XFS would be fully usable, though: XFS buffer management is pretty full-on. The filesystem maintains its own pool of kernel buffers separate from the VM page cache which it uses for aggregating I/O transfers (so that if, say, you make 5 separate out-of-order I/Os which just happen to blanket a contiguous region of a disk object, XFS will collapse them into a single I/O; it'll also take small contiguous regions (extents) and remap them into the next-power-of-two extent size as they grow. I know I could probably see by looking at the source, but does FreeBSD still impose a 64k limit on physical I/O operations? That'll have to go too... - mark Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Source code of SGI XFS
Pavel Narozhniy wrote: Does anybody heard about SGI releasing XFS source code? Yup, they're doing it. I would guess that FreeBSD would need a fairly thorough revamp of its handling of kernel memory allocation before XFS would be fully usable, though: XFS buffer management is pretty full-on. Read Irix has shitty block I/O support so XFS has to do it all itself. The filesystem maintains its own pool of kernel buffers separate from the VM page cache which it uses for aggregating I/O transfers (so that if, say, you make 5 separate out-of-order I/Os which just happen to blanket a contiguous region of a disk object, XFS will collapse them into a single I/O; We do this too; it's called I/O clustering, but it's done below the filesystem so that anyone and everyone can benefit from it. it'll also take small contiguous regions (extents) and remap them into the next-power-of-two extent size as they grow. Whatever that means. 8) I know I could probably see by looking at the source, but does FreeBSD still impose a 64k limit on physical I/O operations? That'll have to go too... Nominally. We ought to be able to support fragmentation as required to support the underlying device, but it's not complete yet. The fixes are relatively trivial. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Source code of SGI XFS
On Sat, 22 May 1999, Mark Newton wrote: Pavel Narozhniy wrote: Does anybody heard about SGI releasing XFS source code? Yup, they're doing it. I would guess that FreeBSD would need a fairly thorough revamp of its handling of kernel memory allocation before XFS would be fully usable, though: XFS buffer management is pretty full-on. The filesystem maintains its own pool of kernel buffers separate from the VM page cache which it uses for aggregating I/O transfers (so that if, say, you make 5 separate out-of-order I/Os which just happen to blanket a contiguous region of a disk object, XFS will collapse them into a single I/O; uh, we already do that don't we? it'll also take small contiguous regions (extents) and remap them into the next-power-of-two extent size as they grow. we do this for growing frags too. I know I could probably see by looking at the source, but does FreeBSD still impose a 64k limit on physical I/O operations? That'll have to go too... - mark Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
