iallocAsync

[Craig Varrichio]

Is there something I'm missing here? It seems like this is intended to call
readInodeReq, thus differentiating it from iallocSync. But if so, it cannot
be guaranteed to actually return an inode. If it does not do any read
requests, then what makes it different from iallocSync?

[Yiu Fai Sit]

no. you should call writeInodeReq(). You can actually find a free inode
right away and return it, but the write to inode is through
writeInodeReq(), which is asynchronous.

Sit

[Craig Varrichio]

Wait, why do we have to write to the inode? Our iallocSync didn't write
inodes - there isn't any information in ialloc to write to an inode.

"Yiu Fai Sit" <yf...@cs.utexas.edu> wrote in message
news:d54kh2$j59$1...@news.cs.utexas.edu...

[Craig Varrichio]

But we do have to do a read - our previous iallocSync did have a call to
readInode, which was used to form the inode that was passed back.

"Yiu Fai Sit" <yf...@cs.utexas.edu> wrote in message
news:d54kh2$j59$1...@news.cs.utexas.edu...

[Yiu Fai Sit]

I meant inode bitmap. sorry about that.

For the need of reading in an inode, that depends on how you implement
iallocAsync. but as long as you do all the reads and write in an
asynchronous manner, that's fine.

Sit

[sg]

Sit, aren't we guaranteed that all of the first five blocks are already in
the buffercache as they are loaded on initialization?
If this is the casae, any writing back of inodes will always hit the cache
in which case we don't need to worry about doing it asynchronously right?
Thanks,
Sam
"Craig Varrichio" <cvar...@mail.cs.utexas.edu> wrote in message
news:d56lh4$cpf$1...@news.cs.utexas.edu...

[Yiu Fai Sit]

It think it is. you can refer to the thread "startup before syscalls".
but you have only the first 5 blocks initially, so some inode blocks are
not in the cache.

Sit

[Adrian Kubala]

sg <s...@sg.sg> schrieb:

> Sit, aren't we guaranteed that all of the first five blocks are already in
> the buffercache as they are loaded on initialization?
> If this is the casae, any writing back of inodes will always hit the cache
> in which case we don't need to worry about doing it asynchronously right?

Inodes can be in other blocks besides the first one.

[sg]

Sorry, I was refering to updating the inode bitmap. I am still having
problems loading the first 5 blocks into the cache. It seems like the call
sequence should be as follows:

1. bc.readAsync()
2. bd.read()
3. d.read() (which puts the event in the callbackmanager)

However, when the os is interrupted with these first 5 pages returning from
disk, no callBack method is called. How are we supposed to load the pages
into the bufferCache? I think I am still missing a huge piece here.

"Yiu Fai Sit" <yf...@cs.utexas.edu> wrote in message

news:d5qo82$o05$1...@news.cs.utexas.edu...

[Adrian Kubala]

sg <s...@sg.sg> schrieb:

> Sorry, I was refering to updating the inode bitmap. I am still having
> problems loading the first 5 blocks into the cache. It seems like the call
> sequence should be as follows:
>
> 1. bc.readAsync()
> 2. bd.read()
> 3. d.read() (which puts the event in the callbackmanager)
>
> However, when the os is interrupted with these first 5 pages returning from
> disk, no callBack method is called. How are we supposed to load the pages
> into the bufferCache?

The OS does this for you (see OS.interrupt); it fills the MemPage (which
is in the buffer cache). Maybe you forgot to put the correct MemPage
into the OSEvent when you created it?