summaryrefslogtreecommitdiff
path: root/2005/flow-accounting-ols2005/OLS2005/denijs/denijs-abstract.tex
blob: f8213005ad7ba3c3df3f60f4ad51515a7e300bb5 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
%  [1]>linuxsymposium                      July 20-23rd, 2005, Ottawa, Canada 

%     Registration          Active Block I/O Scheduling System (ABISS)        
%                                                                             
%  [2]Register/Submit Giel de Nijs (giel.de.nijs@philips.com)                 

The Active Block I/O Scheduling System (ABISS) is an    
extension of the hard-disk storage subsystem of Linux.  
It is designed to provide guaranteed reading and        
writing bitrates to applications, with minimal overhead 
and low latency. The core element of ABISS is a         
scheduler that performs intelligent read-ahead or       
write-back, based on the access profile the application 
has previously requested. An adaptation of existing     
work on incorporating support for priority requests     
into the elevator (``IO scheduler'') is part of our       
implementation, and enables ABISS to ensure that        
real-time requests are served in a timely manner.       
Besides the extension to the storage subsystem, we have 
implemented experimental support for delayed allocation 
in the FAT file system, to be effectively able to       
provide the guaranteed writing bitrates. We are working 
on combining this with disk space reservations, which   
are also part of on-going development on ext3.          
Applications use the regular POSIX API, and control the 
ABISS extensions either directly through ioctls, or a   
library offering simple wrapper functions. ABISS        
contains by a user-space demon that oversees resource   
allocation and handles admission control. Also some     
minor modifications were made to file system drivers.   
ABISS currently supports FAT, VFAT, ext2, and ext3. In  
a set of experimental runs with real-life data rates on 
a deliberately not very powerful test system reflecting 
a typical embedded device, we have measured that all    
read and write operations completed within 6 ms, while  
a background load of eight concurrent greedy readers or 
writers, served in a best-effort way, experienced       
delays worse by a factor of more than 4000.             

personal git repositories of Harald Welte. Your mileage may vary