chrisj at rtems.org
Thu Aug 4 06:04:54 UTC 2011
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
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
> 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.
More information about the users