Hi,
I am also in the process of writing my first FS so I am definitely not
an expert, nevertheless I think I can answer some of your questions.
On 7/16/05, Jason J. Herne <hernejj@xxxxxxxxxxxx> wrote:
> I think I've done lookup, create, and alloc_inode somewhat correctly.
> What I do not understand is prepare_write() What is it supposed to
> do?
Many filesystemes (minix, ext2, ext3) use the generic_file_write
function to handle the write syscall. prepare_write address space
operation is then nothing but a callback from this function. As far as
I know it has to do two things:
1. Make the page "Uptodate" which means that the copy in memory cache is
not older than what is on the disk.
2. Make sure (as much as possible) that the write will succeed if
this function
does not return an error. This can mean about anything but many
filesystems
just check there is enough free space if new blocks must be
allocated, most
actually allocate them (on disk) straight away.
BTW, there is also commit_write aops that is called right after the
data are copied to the cache. The generic implementation just marks
corresponding buffers and the whole page dirty, so that the page is
actually written out by memory manager calling the writepage or
writepages address space method. Prepare_write, copying the data and
commit_write then form a typical two phase transaction interface that
is useful for various journalling filesystems.
> Also, what is get_block() supposed to do?
> for reference:
> int bfs_get_block(struct inode * inode, sector_t block, struct
> buffer_head * bh_result, int create)
get_block is supposed to map buffer bh_result to the corresponding
block on the device, given the inode and logical number of the buffer
in file.
> I also gather that if 'create' is non-zero and I do not find the given
> block because it is at the end of the file, I should extend the file so
> that it includes the request block??
Well, yes. This also applies if there is a hole in the file (with
create nonzero).
> I wrote prepare_write by following BFS's code and it just calls
> block_prepare_write and passes get_block as the last parameter. So
> get_block gets called.
Ext2 does the same thing, ext3 does a lot of journalling around the
call but calls it nevertheless.
> When get_block gets called via prepare_write, since my inode (for some
> reason) does not seem to exist on the disk yet, I cannot step through my
> on-disk inode list and find the inode given by the 'inode' argument to
> the get_block function. Should my new inode exist on the disk yet?
I reckon this is a filesystem specic or even filesystem implementation
specific question. For example, we don't require it, others may.
> In the situation above, what am I supposed to do in get_block?? Should
> I allocate a block for this file and initialize the bh_result argument
> to get_block?
Have a look at ext2_get_block. What you need to do is call map_bh if
the block exists on the disk or you have just allocated it (depending
on the create parameter - then you also must set its "new" flag).
If you don't understand pages, buffer head and so I would also suggest
you read a source of a filesystem like minix (easy) or ext2
(effective). Unfortunately, there is no faster or easier way that I
would know of.
HTH
Martin Jambor
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
