Check out the new USENIX Web site. next up previous
Next: Experimental Results Up: Implementation Previous: Victim list Management

Interface to Applications

We have implemented an interface for use by privileged applications to access the data and services of the driver. The motivation for introducing this interface was to implement only mechanisms inside the kernel and offload policy decisions to user level applications. These are implemented as ioctl()s.

Get Maptable Address Using this ioctl(), an application can get the kernel virtual address of the maptable and the number of entries in it. The application can then perform an open() on /dev/kmem and mmap() the region into its address space. As the access frequency information is also kept in the maptable entries, the application can keep track of how often a stripe has been accessed without making any further calls to the kernel.

Get Bitmap And Maptable Using this ioctl(), an application can read copies of the allocation bitmap and the maptable frozen at some point in time. The driver locks the entire maptable (by setting an interlock that spans the entire device), and then the maptable and the bitmap are copied into the user buffer and the lock on the maptable is released. Using this information, an application can compare the allocation bitmap against the maptable to find if any of the physical stripes have gone unaccounted which can happen when the system fails when a migration is in progress. The application (eg. device-check) can then fix this by using another ioctl(). Since the temperature information is also available in the maptable, the application can know the temperature without making further calls to the kernel.

Get Compressed Table Address Using this ioctl, the user application can access the compressed table and hence can get information about every compressed stripe, such as compressed length and physical stripe backing for this stripe.

Get Access log Using this ioctl(), an application can get the kernel virtual address of the access log and the number of entries in it. The application can then call open() on /dev/kmem and mmap() the region into its address space and keep track of the accesses without making any more calls to the kernel.

Migrate Given a RAID1 stripe and a RAID5 stripe, this ioctl() migrates the RAID1 stripe to RAID5 and vice versa. This ioctl() along with the former can be used by an application to keep track of access patterns and perform prefetching. The application can maintain its data structures in user space which do not pin memory down. To reduce the system call overhead, multiple requests can be grouped together and passed as a list. The request is failed if any of the stripes has already changed the type.

Age The maptable can be aged using this ioctl(). This way we implement software LRU for maintaining the access frequencies of stripes. The accessed bit is ORed with the temp field after it is shifted to right by one bit. The accessed bit is then cleared. Aging is also performed from within the driver during victim list reconstruction if sufficient RAID1 stripes are not found to fill the list.

Sync Meta Data This results in all meta data structures being updated to stable storage.

Punch Hole A given RAID5, cRAID5 or RAID1 stripe is marked an invalid stripe and the backing physical stripes are released.

Migrations from/to cRAID5 These ioctls try to migrate RAID1/RAID5 to/from cRAID5.

cRAID5 Move This ioctl allows us to move the cRAID5 stripe from one physical stripe to another physical stripe as backing store. This ioctl can be used by an user level application to take policy decisions for compaction.


next up previous
Next: Experimental Results Up: Implementation Previous: Victim list Management
Dr K Gopinath
2000-04-25