|
CO527 Anonymous Questions and Answers |
This page lists the various questions and answers. To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.
We have taken the liberty of making some minor typographical corrections to some of the questions as originally put. Although most of the questions here will have been submitted anonymously, this page also serves to answer some questions of general interest to those on the course.
Submission reference: IN958
Hi Fred, My solution works fine for test.dsk and badtest.dsk but a lot of the files in bigger.dsk don't read. After putting in a debugging statements, I found that I couldn't read inodes with an offset above 63. I know that there can only be 64 inodes in an inode table, since each inode is 64 bytes and a block is 4096 bytes... I know that I can't read inodes with an offset above 63 because I made it return null in that case since the ioffset would be invalid. I've tried raising the ioffset validity check but that results in an indexOutOfBounds exception which is what I expected. Well hopefully this makes sense to you because I'm a bit confused. Any ideas where I've gone wrong? Thanks.
One of your assumptions is wrong. Why can't inode tables be bigger than a single block? Sure, the number of inodes per block is limited to 64, but there's no reason why the inode tables can't span multiple blocks! — and this what happens in bigger.dsk. If you look at the output on the screen prior to your code running, you'll see this:
Inode tables at : (2-11) (12-21) (22-31) (32-41) (42-51) ...
So, clearly, inode tables can and do span multiple blocks..!
Keywords: coursework
Referrers: Question 124 (2006) , Question 141 (2006) , Question 145 (2006)
Submission reference: IN959
Can you clarify me something pls? Itable is the whole array of the inode_offset? Or just a part of the inode_offset? Thnx
I'm afraid I don't understand your question. Sounds like you're quite confused.. :-(
I'd recommend looking at other anonymous questions relating to the coursework, where I've attempted to explain some of these things.
Keywords: coursework
Submission reference: IN966
Does a block always have 64 inodes?
Yes (from block-size/inode-size, and these values are fixed for the file-system).
Keywords: coursework
Referrers: Question 124 (2006)
Submission reference: IN964
Fred, I have struggled my way through this assessment and have finally got some decent output! However my output still doesn't look quite like yours, for the test.dsk I get...
0x1000000 512 0 0 .
0x1000000 512 0 0 ..
0xc00003a 0 0 0 rs422code.c
0xc000011 0 0 0 16dpy.c
0xa000017 0 0 0 ATmegaBOOT.c
0xf000039 0 0 0 gen11.c
0x200001f 0 0 0 gen10.c
0x700001e 0 0 0 sched.c
and the other disks are the same, I have looked at the bit of SmallFS that prints out the final values and it looks like I'm missing all of the inode information. My code is below....
[snip code]
Am I missing out something blindingly obvious here? Seems like I'm close but I've just missed out a whole step of the process....
The error in the code is only slight.. but I'm not a debugger :-). The reason for the broken output is hinted at in some of the answers to other questions, but more than likely it's because something's wrong with the value(s) your code's returning. Clearly, the root inode is being read correctly (because it manages to read its directory contents ok); see if there's anything significantly different about the root inode number compared to the others.. Then read the method header carefully (particularly the emphasised bits), Question 121 (2006) and Question 123 (2006).
Keywords: coursework
Submission reference: IN965
So does the itable consist of blocks? And does the offset of the blocks is in the itable_offset?
I know we're computer-scientists (or electronic engineers), but please try and write grammatically correct English :-). Badly phrased questions lead to misinterpretations, which won't help anybody.
The inodes are contained within disk blocks — specifically the disk blocks allocated to inode-tables, which are listed in the summary information from the superblock; if that's the question you were asking. The itable_offset values in the superblock indicate at which disk blocks the various inode-tables start.
Keywords: coursework
Submission reference: IN967
Hi, I'm currently getting the same output as Question 90 (2006), where I successfully manage to get a directory listing but there are no details of filesizes or permissions. This is my code:
[snip code]
I think my code for getting the block number is OK, and so I think there's just something wrong with my code for getting the offset — it looks too simple. Do we need to do anything more than ... to retrieve it?
Yes, there is a problem with your handling of the offset. The answer lies in two pieces of information that I've already given to you, specifically:
/* * inode numbers are referred to in the following way: * 0xttoooooo ((itable << 24) | (ioffset & 0x00ffffff)) * where 'itable' is the relevant inode table (given in the superblocks) * and 'ioffset' is the inode number within that table. */
from sfstypes.h, and:
/** * takes an inode number and if valid, returns a pair of integers indicating * where the inode data starts, with index 0 containing the block number * and index 1 containing the byte offset within that block; * if the specified inode number is invalid, returns NULL. * * @param inode inode number * * @return integer array containing location as described, or NULL on failure */
from SmallFS.java (method header on what you have to implement). Look carefully at the text regarding offsets...
Keywords: coursework
Referrers: Question 127 (2006) , Question 130 (2006)
Submission reference: IN972
I realise I'm missing something completely but was wondering if you could help? I'm having the same issue as Q119 and I've tried for hours to work out what I've missed but I can't.
[snip code]
I think its the offset that's wrong and I have to do something with that like the table but I can't for the life of me work out what. Could have have a pointer in the rough direction before I jump out the window?
See the answer to Question 126 (2006), which is essentially the same problem. There's still some time to go before the deadline, so I might give a bit more help next week — in the meantime, look at the values you're returning for the byte offset of the inode, and see if these make sense..
Leaping from a window would probably have its concessionary benefits, but not good for your health, or legs. Of course, I'd never recommend such an action.
Keywords: coursework
Referrers: Question 129 (2006) , Question 139 (2006)
Submission reference: IN974
Hi, is there something we have to take into account when considering a byte offset? At the moment I am doing something to the tune of:
[snip code]
which produces the output (for test.dsk):
[snip debugging output]
Are those the correct offsets? it is worrying that you mention a byte offset, where I am only using ints. I have been stuck on this problem for hours!! if you could point me in the right direction it would be fantastic... thanks!
With regards to your last point about a byte offset being held in a integer, that's fine (and quite necessary, since byte offsets are in the range 0-4095, and a byte itself can only hold values 0-255 — ignoring signedness issues).
Taking one of your debug/program outputs:
inode: 201326609 itable: 12 offset : 17 0xc000011 0 0 0 16dpy.c
This is presumably returning some relevant block number and an offset value of 17. But this offset is an inode offset, not a byte offset. Each inode is 64 bytes, and they are packed neatly into blocks, so an inode must begin on a byte offset which is a multiple of 64; 0, 64, 128, 192, 256, ...
Hopefully this will shed some light on the problem.
Keywords: coursework
Referrers: Question 130 (2006) , Question 134 (2006) , Question 139 (2006) , Question 145 (2006)
Submission reference: IN975
Hi me from Question 127 (2006) again. Tried it out of netbeans with a fresh copy of the source files, a fresh copy of the disk and then my friend and I tried pasting his code in (which works on his machine) and running from the command-line and it still comes up with 128 as the size
Is this a compatibility issue with jdk 1.6.0? It really can't be much else can it?
Given the scenarios you've described, I'd have to agree that it's either a JDK 1.6 issue, or something peculiar about the hardware you're running on. I don't have a Java 1.6 install (yet), so can't try this out right now, but will attempt to at some point. In the meantime, I'd suggest reverting to a 1.5.0 install. If the problem doesn't go away, then it's probably something else. What JVM (Sun/IBM/etc.) are you using, and on what hardware/platform?
Keywords: coursework
Referrers: Question 140 (2006)
Submission reference: IN979
I am having this code:
[snip code]
But when I run it I get:
SmallFS::getBlocksFromInode(): indirect inode not supported yet! SmallFS::fsDumpRoot(): failed to read directry entry 0 of 22369621 SmallFS::fsDumpRoot(): failed to read directry entry 1 of 22369621 SmallFS::fsDumpRoot(): failed to read directry entry 2 of 22369621 SmallFS::fsDumpRoot(): failed to read directry entry 3 of 22369621 ...
I have read Question 99 (2006), but it didn't make sense. Can you have a look at my code and give me a hint about where is the mistake? Thanks.
You've got some fairly odd looking code in there, which looks like a chunk copied out of the initFS() method. It's sort of heading in the right direction. As to why your code fails, it's because the location of the root inode is being returned incorrectly. See Question 126 (2006) and Question 128 (2006).
Keywords: coursework
Referrers: Question 133 (2006)
Submission reference: IN980
Can you explain to me how daemons in Unix are related to I/O?
Not simply.. Any decent book on Unix will explain the purpose of daemons in some detail, and most operating-system textbooks will cover the concept. Almost all daemons do some form of I/O — they wouldn't be much use otherwise. Common Unix examples would include: "sshd", which is the secure-shell daemon, responsible for handling logins via ssh; "lpd", which is the line-printer spooler (and generally manages print queues); "nfsd", which handles remote file-system requests for NFS; and a whole load of others.
Keywords: input-output , unix
Referrers: Question 208 (2006)
Submission reference: IN981
Hi, Firstly, a quickpointer that the test.dsk in the zip file doesn't appear to be the same as the test.dsk not in the zip file. This is slightly confusing - I only tried the separate download on a hunch.
Also, could we please have a huge.dsk which references a file right at the end of the disk? This would allow us to test disks with multiple-block inode tables and much higher values than test.dsk has. Thanks in advance
I've fixed the zipfile (created a new zipfile), thanks for pointing that out. As to bigger disks, see Question 94 (2006) and Question 105 (2006) — these files are now linked from the assessment web-page.
Keywords: coursework
Submission reference: IN982
In reference to Question 130 (2006). The reason why I copied a large piece out of the initFS() method, is that I wanted to check whether or not the inode number is valid. Is is the correct way of doing it or not?
Partly. The code in initFS is doing something different however — it's just reporting the block locations of the inode tables there, and not actually doing any checking of any kind. But you will need to look at the relevant superblock data (itable_...) in order to do this assessment, so the code will be vaguely similar, but not verbatim.
Keywords: coursework
Submission reference: IN983
So the byte offset has to be returned as a multiple of 64. Isn't it?
According to Question 128 (2006), yes.
Keywords: coursework
Referrers: Question 145 (2006)
Submission reference: IN985
I'm really struggling to get my head around this coursework. Could you possibly give me an example of the data to be returned (e.g., the array to be returned for the root inode), as I am not even sure of that.
The root inode number, 0x01000000, indicates that the inode is in table 1 at offset 0. Looking at the superblock summary data printed for test.dsk, inode table 1 lives in disk block 3. So the first integer returned should contain 3; the byte offset within the inode table block, in this case, is zero. So your code should produce the array [3,0] for the root inode, but only for test.dsk — other disk images may vary.
Keywords: coursework
Submission reference: IN989
Can you give us the result for the badtest.dsk? Thanks Fred.
Keywords: coursework
Submission reference: IN990
I'm completely lost here:
[snip code]
I think I am getting the inode table location correctly here, but I have no idea how to do the offset — I have been working at this for a long time and seem to be getting nowhere, so any input you can give me would be greatly appreciated!
Yes, there's something broken with your handling of the offset. The way you extract the inode offset from the inode number results in numbers which are a multiple of 256 — see Question 118 (2006). That bit's not right.
Keywords: coursework
Submission reference: IN991
I was just looking at Question 98 (2006). You said that the offset is contained in the lower 24 bits and the table in the top 8 bits. But I did System.out.println to see what was being passed to my getInodeLocation method and got the decimal number 16777216 - this number in binary is 1 followed by 24 0s - so there aren't enough bits to do this. Am I going about this in the right way?
Yes, you're approaching it in the right way. As you point out, the value (in hexadecimal, rather than binary) is 0x01000000. The 24 low-order bits are zero, meaning that the inode offset is zero. The inode table is 1. See also Question 118 (2006).
Keywords: coursework
Submission reference: IN992
Hi, can you give me any hints as to where I can find the byte offset information the getInodeLocation method needs?
See Question 127 (2006) and Question 128 (2006).
Keywords: coursework
Submission reference: IN993
I'm befuddled now! I'm getting some sort of an answer, but the code seems to stop after the first few lines:
inode: 16777216, itable: 3, offset: 0 inode: 16777216, itable: 3, offset: 0 0x1000000 128 0 0 . inode: 16777216, itable: 3, offset: 0 0x1000000 128 0 0 ..
(with a bit of debugging info). The code I have for this is:
[snip code]
and while I don't want you to be a debugger, can you at least prompt me in the direction of where I'm going wrong, as its really annoying me now!
That output is sort of correct. Regarding the lack of other output, check that you're using the latest test.dsk image (it requires re-downloading for assessment 4, as stated on the web-page). But the "size" value you're seeing of 128 is wrong. See Question 129 (2006).
Keywords: coursework
Referrers: Question 144 (2006)
|
Maintained by Fred Barnes, last modified Thu May 8 12:58:00 2014 |
