libblock

[Mick Davis]

Thanks for the help Chris, Sebastian.

I think this is going to work for me. I was concerned with the user 
being able to update a file such that after an unexpected power loss, 
either the old or new versions are available.  If I use the block driver 
with RFS, it looks as though I need to;

rename old file
write new file,
close it
open the device driver, use ioctrl for a sync

That would suit me.  Support for fsync through RFS to the block device 
would just be a bit more portable.


On 08/04/2011 02:04 PM, Chris Johns wrote:
> 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
>

-- 

Mick Davis
Goanna Technologies Pty Ltd
+61 8 9444 2634