libblock

[Chris Johns]

On 4/08/11 3:04 PM, Mick Davis wrote:
>
> I'm considering implementing a custom filesystem adaptor using the
> libblock. Its for what looks like some fairly unique hardware. I've been
> looking at the flashdisk and ramdisk examples.
>

Do you mean a driver that sits below libblock ?

> As I see it, I'd implement a 'register' function for the user app to
> run, which uses rtems_disk_create_phys() to connect my ioctrl()
> function. I'd then get read/write ioctrls containing the blocks.
>
> I'm wondering about how to get somewhat efficient storage. How is a file
> composed from blocks?

This is a function of the file system that you use. The DOSFS uses a FAT 
and chains and clusters, the RFS uses blocks, bitmaps and inodes.

> Suppose I have a file containing a few bytes of
> data, how many blocks might my adaptor receive ?

Again this depends on the file system and how that is configured. The 
driver will declare a media block size and the file system should allow 
a file system block size. For example an IDE disk has a media block size 
of 512 bytes and you would use 4096 byte block size with the RFS for a 
large multi-gigabyte disk. If you did not the overhead to handle the 
metadata would become an overriding factor. For small files this means 
4096 bytes will be allocated per file.

>
> Is the block cache implemented for me? How are written blocks cached
> before writing out to my adaptor?
>

The libblock contains a cache. The cache consists of buffers of various 
sizes. The cache can dynamically re-size buffers to support different 
file system and media block sizes from a common pool of memory. The 
buffers contain the blocks from a device in an AVL tree and the key is 
the device and block number. When the file system requests a block it 
checks the cache and if not present frees a buffer and asks the driver 
to fill it. This is then returned to the file system layer. When the 
file system has finished it indicates if the buffer has been modified. 
If not modified nothing more happens and the data remains in the cache 
until the buffer is needed or the data accessed again. If the buffer has 
been modified a timer is started. If the file system requests the buffer 
again it is returned. The timer keeps running but the buffer will not be 
passed to the driver until the file system returns it. Once returned and 
the timer has triggered a swapout worker thread will pass the buffer to 
the driver to write to the media. You can control the size of the 
memory, maximum size of a block, write timer and number of work threads.

> Will all changed blocks get pushed out when the file is closed after
> writing?

This is a function of the file system, the cache configuration and your 
application. The RFS will flush all file state data including file data 
and metadata on a close. You need to request a sync to the device to 
have the data flushed from the libblock cache from your application.

The sync'ing in RTEMS is weak. The sync call is currently limited to the 
libc support and it's implementation is questionable. The RFS does not 
have sync support and this is something I need to add. Libblock has sync 
support that is synchronous to the caller. The is documented in PR 1848 
(http://www.rtems.org/pr1848)

>
> Suppose I need to assemble blocks together for writing in groups. Will
> the cache do this for me? Or can I get a signal when a file is closed?
>

Drivers have no idea about files. They only see blocks. A file depends 
on the file system.

Chris