FAT File system questions.

[Victor V. Vengerov]

Daniel,

Daniel Gustafsson wrote:

>I want to use eight ramdisks, 1 Gbyte each, and use them similair to
>partitions. 
>
>Example:
>
>/mnt/ramdisk0
>/mnt/ramdisk1
>...
>
>The ramdisk will be rewritten to access non-volantile RAM over a network
>link. 
>
You mean you are planning to implement network-attached storage device 
driver? If so, let name it differently...

>Due to the limitations of working memory (RAM) in my system i really
>need to know how I can tune this value. I am REALLY interested how the bdbuf
>works.
>  
>
I definitievly should document this. Until this happens, I have to 
respond :-)

bdbuf is just a LRU cache in RAM of blocks normally stored on the 
storage device (hard disk, compact flash, or, like in your case 
network-attached RAM-based (?) storage).

bdbuf configuration normally stored in the rtems_bdbuf_configuration 
variable. This is array describing the pools of buffers; separate pools 
needed for different block sizes. For example, you may find definition 
of this variable in c/src/tests/samples/fileio/system.h - there are 128 
buffers for 512-byte blocks initialised. Third member, which is NULL, is 
a buffer memory pointer (to allow using of dedicated memory area for I/O 
buffering, e.g. to use non-cacheable mapping).

We are carefully designed and tested file system and bdbuf code to make 
it working with single block buffer. In this case, no blocks cached, and 
device is accessed every time when new block touched.

>How and when are the different FAT tables resident in RAM? A only want to
>have one FAT in RAM at a time, how is this done in the best way?
>  
>
Normally FAT not persistent in the RAM. FAT stored on the block media, 
and FAT blocks are accessed as any other blocks. Although, because of 
frequent accesses of FAT, it is likely that all FAT blocks appears in 
the bdbuf cache (if enough memory is configured).

Is it really important to lock all FAT blocks in the RAM? May be LRU 
caching OK for you? Currently there are no interface to lock specific 
blocks in the memory, although, at first glance, it is possible to add 
it, although it will be little ugly. Anyway I should think and check this.

>How does the thread that flushed buffered block down to disk at various
>times work? Can I tune this in any way?
>  
>
Swapout task wake up when someone (e.g. file system code) mark block(s) 
modified. This thread pass modified blocks to the block device driver, 
one by one, to flush them to the media.

Swapout task configuration (task priority and stack size) is static 
currently. Swapout task has a name, BSWP. Generally, you may change 
task's priority finding task handle by name, although I'm not too 
enthusiastic about it.

Generally, all your manipulations should be done in block device driver. 
bdbuf layer calling ioctl of this driver to execute read or write 
operations, and it is driver responsibility to deal with it. I see no 
problem to implement block device driver for network-attached storage, 
using proprietary, very simple protocol. I can imagine very special 
driver, which will perform buffering itself (and locking of FAT blocks 
if necessary), which will implement custom policy of block flushing, 
although I'm not sure it is reasonable... Think twice before doing so.

>What does ide_part_table_initialize() do. Is it nessasery to use when using
>a formatted (doerfler function) ramdisk (my system seems to work both with
>it and without it)?
>  
>
ide_part_table_initialize() makes attempt to find partition table on the 
device, and create logical devices corresponding to partitions. This is 
to allow to have several file systems mounted on the same device, to 
follow compact flash and other card formatting conventions etc. Because 
partition table is not initialised on ramdisk device, 
ide_part_table_initialize() founds no partition table and do nothing.

I think you normally not need to call ide_part_table_initialize(), 
although it depends.

Hope this helps,
Victor


-- 
Victor Vengerov
OKTET Labs, St.-Petersburg, Russia  http://www.oktetlabs.ru
Phone: +78124286709 (office) +78129389372 (mobile) +78124281653 (home)