Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> --- .../allocation_groups.asciidoc | 17 +++++++++- design/XFS_Filesystem_Structure/docinfo.xml | 1 + .../internal_inodes.asciidoc | 35 +++++++++++--------- 3 files changed, 36 insertions(+), 17 deletions(-) diff --git a/design/XFS_Filesystem_Structure/allocation_groups.asciidoc b/design/XFS_Filesystem_Structure/allocation_groups.asciidoc index 346f1b2..9ba26c2 100644 --- a/design/XFS_Filesystem_Structure/allocation_groups.asciidoc +++ b/design/XFS_Filesystem_Structure/allocation_groups.asciidoc @@ -909,5 +909,18 @@ been fully allocated. [[Real-time_Devices]] == Real-time Devices -TODO - +The performance of the standard XFS allocator varies depending on the internal +state of the various metadata indices enabled on the filesystem. For +applications which need to minimize the jitter of allocation latency, XFS +supports the notion of a ``real-time device''. This is a special device +separate from the regular filesystem where extent allocations are tracked with +a bitmap and free space is indexed with a two-dimensional array. If an inode +is flagged with +XFS_DIFLAG_REALTIME+, its data will live on the real time +device. The metadata for real time devices is discussed in the section about +xref:Real-time_Inodes[real time inodes]. + +By placing the real time device (and the journal) on separate high-performance +storage devices, it is possible to reduce most of the unpredictability in I/O +response times that come from metadata operations. + +None of the XFS per-AG B+trees are involved with real time files. diff --git a/design/XFS_Filesystem_Structure/docinfo.xml b/design/XFS_Filesystem_Structure/docinfo.xml index a6a992b..9bcecad 100644 --- a/design/XFS_Filesystem_Structure/docinfo.xml +++ b/design/XFS_Filesystem_Structure/docinfo.xml @@ -86,6 +86,7 @@ <member>Add some missing xfs_db examples.</member> <member>Add an overview of XFS.</member> <member>Document the journal format.</member> + <member>Document the realtime device.</member> </simplelist> </revdescription> </revision> diff --git a/design/XFS_Filesystem_Structure/internal_inodes.asciidoc b/design/XFS_Filesystem_Structure/internal_inodes.asciidoc index 837f025..c21f8b4 100644 --- a/design/XFS_Filesystem_Structure/internal_inodes.asciidoc +++ b/design/XFS_Filesystem_Structure/internal_inodes.asciidoc @@ -160,24 +160,29 @@ Bitmap Inode and the Summary Inode. [[Real-Time_Bitmap_Inode]] === Real-Time Bitmap Inode -The Bitmap Inode tracks the used/free space in the real-time device using an -old-style bitmap. One bit is allocated per real-time extent. The size of an -extent is specified by the superblock's +sb_rextsize+ value. +The real time bitmap inode, +sb_rbmino+, tracks the used/free space in the +real-time device using an old-style bitmap. One bit is allocated per real-time +extent. The size of an extent is specified by the superblock's +sb_rextsize+ +value. The number of blocks used by the bitmap inode is equal to the number of -real-time extents (+sb_rextents+) divided by the block size (+sb_blocksize+) and -bits per byte. This value is stored in +sb_rbmblocks+. The nblocks and extent -array for the inode should match this. - -[source, c] - xfs_ino_t sb_rbmino; +real-time extents (+sb_rextents+) divided by the block size (+sb_blocksize+) +and bits per byte. This value is stored in +sb_rbmblocks+. The nblocks and +extent array for the inode should match this. Each real time block gets its +own bit in the bitmap. [[Real-Time_Summary_Inode]] === Real-Time Summary Inode -The Summary Inode keeps the used/free space accounting information for the -real-time device. - -[source, c] - xfs_ino_t sb_rsumino; - +The real time summary inode, +sb_rsumino+, tracks the used and free space +accounting information for the real-time device. This file indexes the +approximate location of each free extent on the real-time device first by +log2(extent size) and then by the real-time bitmap block number. The size of +the summary inode file is equal to +sb_rbmblocks+ × log2(realtime device size) +× sizeof(+xfs_suminfo_t+). The entry for a given log2(extent size) and +rtbitmap block number is 0 if there is no free extents of that size at that +rtbitmap location, and positive if there are any. + +This data structure is not particularly space efficient, however it is a very +fast way to provide the same data as the two free space B+trees for regular +files since the space is preallocated and metadata maintenance is minimal. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
