|
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: IN887
I got my code to work for test.dsk and exact.dsk and have now changed the code to work for the large.dsk, but it keeps throwing an array out of bound error. Here's the code:
[snip code]
can you point out where I'm going wrong?
I am not a debugger :-). See the answer to Question 80 (2006). There was also a lot of duplicated code in what you pasted there — this is a bad thing!
Keywords: coursework
Submission reference: IN888
What is the maximum number of blocks one bitmap can hold ? Thanks
I assume that you mean, how many blocks can be represented in one block of bitmap data (there is only one bitmap, but it can span multiple blocks). In which case the answer is 16384 (calculated from block-size in bits (4096 * 8), divided by bits-per-block-status in the bitmap (2)). However, it says this in the included 'sfstypes.h' file:
/* * block bitmap: this is arranged as 2-bits for each block; a single block of bitmap data * will cater for 16384 actual file-system blocks (64 MB file-system). Bits defined as: * * 00 - unused * 01 - reserved (superblock, inodes, block bitmaps, indirect blocks) * 10 - used (file or directory data) * 11 - damaged/nonexistent (unusable block -- e.g. physically damaged, or invalid in bitmap) */
Keywords: coursework
Submission reference: IN889
Hi, I was wondering, what majority of the total marks available will be allocated for our solution's ability to successful read the block bitmaps from the 'large.dsk' file? Thanks.
I haven't finalised the marking scheme yet (I need to see a selection of submissions to see how people have approached it generally, and map that onto my sample answer), but I'd expect a solution which doesn't support large disk images (specifically solutions which don't cater for more than 1 block of bitmap data) to not get more than 60%.
Keywords: coursework
Hey Fred, just noticed something as I was testing my assessment 3 code. The 'test.dsk' file on the website appears to be different to the one in "\\raptor\files\courses\co527\disks\". As such when testing with the answer to assessment 3 you end up with slightly different output. Block summary still adds up to 256 but the blocks are spread out differently.
Yes -- the disk image linked from the web-page is now setup for part 3 (assessment 4). The assessment 4 description has the relevant sample output for that image at the bottom of the page.
Keywords: coursework
Hi, do you have any larger disk images (with more than two blocks of bitmap data)?
Yep, I've just created a 1 gigabyte 'huge.dsk' image and put it in a zipfile on raptor. You can find this as: "\\raptor\files\courses\co527\disks\huge.zip" (which is about a 1 MB zipfile, uncompresses into a gigabyte disk image).
Keywords: coursework
Submission reference: IN902
Hi, As us, CSE/ECE'ers don't have access to raptor off-campus by default, some of us are struggling to obtain the additional test disk images. Could you please make them available on the assesment page or somewhere accessible off-campus so we can actually experiment with them? Thanks
I've now linked the zipfiles from the assessment 3 and assessment 4 web-pages. You should be able to access raptor's filestore through the VPN, however (assuming you have that setup).
Keywords: coursework
Submission reference: IN901
For this assessment, is okay to presume that the maximum number of block bitmaps there will be is 2 ? At the moment my code works fine for all 3 disks but doesnt allow for there being more than 2 block bitmaps. Would I lose marks for this ? Thanks
Yes, chances are that if you hard-code the maximum number of bitmap blocks, some marks will be lost (because it won't handle file-systems above a certain size). A new 'huge.dsk' image has recently been added which is 1 GB big. This has 16 blocks of bitmap data.
Keywords: coursework
Submission reference: IN908
I'm finding the inode description quite baffling. By:
0xttoooooo ((itable << 24) | (ioffset & 0x00ffffff))
Do you mean that you've executed these bitwise operations on the itable and ioffset details to create the final inode identifier (which in this case is 16777216) ... if so, are we supposed to be somehow going backwards through the bitwise ops to get the itable and ioffsets back, or am i overthinking this ?
I pity those who haven't studied C if this is the case ... :)
Yes -- the inode number is the result of those operations. The itable uses a left-shift to move up the table number into the high-order bits; the bitwise-and just ensures that the offset doesn't trample on the bits occupied by the table number. It shouldn't actually be necessary — 0xffffff is 16777215 in decimal (or 224-1), which is far too large to be a sensible inode number/offset.
Going backwards should be straightforward, and doesn't require any knowledge of C! Bitwise shifts, ands, ors, xors, etc. are in Java as well..! (if you haven't come across these, googling for "Java bitwise operators" throws up a whole load of useful stuff, including Sun's Java tutorial on these). The reverse of left-shift is right-shift. Bitwise-and has no inverse operation really (mathematicians may disagree..), but you'd need to do something to get the 'ioffset' value back out of the inode number.
Keywords: coursework
Referrers: Question 89 (2006) , Question 93 (2006) , Question 96 (2006)
Submission reference: IN909
Could you please explain what:
inode numbers are referred to in the following way:
0xttoooooo ((itable << 24) | (ioffset & 0x00ffffff))
means?
See the answer to Question 88 (2006)
Keywords: coursework
Submission reference: IN913
I have this code:
[snip code]
And it seems to work, but when the file list is printed, I get this:
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
(notice there are no permissions/filesizes for the files) I cant seem to fix this (the block is right and the offset seems to be ok) Please let me know what i could do to fix this!
There is a subtle problem with your code, though it took me a moment or two to spot it myself! Hint: read the comment above the method carefully. Your implementation doesn't quite do what it says here.
Keywords: coursework
Referrers: Question 116 (2006) , Question 126 (2006)
Submission reference: IN916
What does "<<" mean? You have it written throughout your code and in the header file.
It's the left-shift operator — shifts the operand left by the specified number of binary digits. Each hexadecimal digit is 4 binary digits, so:
0x0020 << 4 = 0x0200
0x0200 << 2 = 0x0800
0x0800 << 1 = 0x1000
Keywords: coursework
Submission reference: IN920
Is the vertical line '|' (in '((itable << 24) | (ioffset & 0x00ffffff))') a notational delimiter or an inclusive or?
bitwise inclusive or (slightly different from '||', which is boolean, not bitwise).
Keywords: coursework
Submission reference: IN918
Despite reading Question 88 (2006) numerable times, I still don't get what
0xttoooooo ((itable << 24) | (ioffset & 0x00ffffff))
means. Could you elaborate a bit more?
It's describing how the inode number is composed — i.e. as a combination of the inode table number and offset within that table. Some of the other questions should explain this further.
Keywords: coursework
Referrers: Question 96 (2006)
Submission reference: IN919
I think I've got it working through hacking around for a while. My heads a bit of a mess but it seems to work.
Is 'test.dsk' the only working disk containing files? As this is the only one that works for me - the others don't show a lot. If this is so would it be possible to get hold of some more disks and maybe something that could cause a failure? As I'm not sure my checking of the input values are correct. Thanks :)
P.S. You have an awesome t-shirt collection!
Yep, at the moment only 'test.dsk' has files on it. I've put a badtest.dsk image in the 'co527/disks' directory on raptor, which is mostly the same, except it has an error in one of the directory entries. I've also created a 20 MB bigger.dsk image which has a bunch more files on it, but if you get the sample output for 'test.dsk' then things are probably working ok.
thinkgeek.com — for all your geek apparel. :-)
Keywords: coursework
Referrers: Question 105 (2006) , Question 132 (2006)
Submission reference: IN925
I am playing around trying to understand the bitwise operations and have this code:
[snip test code]
Which returns this when run:
[snip test output]
But when I use ... and ... in the assessment I get errors saying:
SmallFS::fsDumpRoot(): failed to read directory entry 1 of 22369621
which I presume will contiue with entry 2, 3, etc forever. Is there something I'm missing with these operations? Thanks.
The way you're using the operators looks fine — something else must be wrong. From the output, something must have gone wrong when reading the root inode, as there are only 8 directory entries on the given 'test.dsk'.
Keywords: coursework
Submission reference: IN926
Hi, Can you please explain what I am supposed to do, I have read the questions page and the sheet a numerous number of times and well, it makes no sense to me, bitwise? I mean what is that... the whole inode number thing?, what am I supposed to do with it?
I have no idea, and once again feel as if I'm bashing my head against a brick wall. :-(
That's a bit unfortunate.. :(. At this point in CS and related degrees, you should be aware of what bits, bytes, etc. are. If need to brush up on these, there is a whole raft of information out there on the internet, and I would suspect, a whole lot of relevant material in the library. Most programming textbooks on Java (or C, C++, etc.) will give a description of these bitwise operators. The knowledge is out there — go look for it! :-). Or alternatively, ask one of your peers (about bitwise operators, not how to code the solution!).
Inodes (or index-nodes) are used to describe files and directories on the file-system. Look at the included 'sfstypes.h' for a description of what the inode is and what it contains. The inode-number is how the file-system refers to these numerically. From assessment 2 you should be aware that inodes are contained in 16 different tables (arrays), which occupy various blocks on the disk. The inode number therefore needs to indicate which table a given inode is in, and whereabouts in that table it is. It does this by the method shown (see Question 93 (2006) and Question 88 (2006)).
Keywords: coursework
Submission reference: IN927
How do we check if the number is valid? Is it invalid if we can't get values from it using the bitwise operations?
If the inode number is invalid, you'll get resulting values which are wrong. But you have to extract those values (table number and offset) first, then you can check them for validity. The table number, for instance, must be between 0 and SFS_NTABLES-1 inclusive. The offset must be valid in that the inode exists in the table (i.e. isn't beyond the bounds the particular inode table). Bear in mind that the offset is expressed in inodes, not bytes, and each inode is 64 bytes long (meaning that there are 64 inodes in each 4096-byte block of inode data).
Keywords: coursework
Submission reference: IN929
Looking through the answers already on this page I mostly understand the bitwise operators that are used in this assessment however how do I find the inverse of a bitwise or and a bitwise and?
The only (dyadic) bitwise operator which has a meaningful inverse function is exclusive or. Bitwise-and, and bitwise-or, have no useful inverse function in the general sense (or rather, none that can be programmed usefully). Instead, consider why these are used to construct the inode number in the first place. Given the hex expression '0xttoooooo', in which the offset is contained in the lower 24 bits (and the table in the top 8 bits), you can get the offset back just by taking the lower 24 bits (and ignoring the top 8 bits).
Keywords: coursework
Referrers: Question 138 (2006)
Submission reference: IN930
I swear that I'm doing it right and getting the right numbers, but I get this error:
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
etc., with the entry number increasing each time. What exactly does the first line mean?
The first line means that the code found an indirect inode; this shouldn't happen. More likely is that your implementation of getInodeLocation() returned incorrect values, which caused other code to read something that wasn't actually an inode (hence the resulting errors).
Regarding indirect inodes (although this is not necessary to know for this part of the assessment), if you look in the supplied sfstypes.h, you'll see that an inode can hold 12 block numbers. That's fine if the file or directory being referred to uses less-than or equal to (4096 * 12) bytes. If it's larger, the block numbers in the inode refer to blocks that contain up to 1024 further block numbers, and those blocks contain the actual file or directory data (hence indirect, as opposed to direct).
Keywords: coursework
Referrers: Question 130 (2006)
Submission reference: IN931
Using some debugging (System.out.println(inode)), I see that the first number supplied as a parameter to the getInodeLocation() method is 167777216, or 0x01000000.
This is format 0xttoooooo thus inode table 0x01 (1) and offset 0x000000 (0).
But there is no inode table in block one because inode tables are values 2 to 16. This causes lots of errors to spew out. Returning null because of an invalid value causes an error to appear instead of the desired output. Clearly I am misunderstanding something, my question is: what?
You're right in that the inode is at offset 0 in table 1, but table 1 does exist — it's block offset and length are printed out as part of the information when the 'initFS()' method is called. The header of the method states (emphasised) that it should return the block number where the inode can be found (and not the inode table number).
Keywords: coursework
Referrers: Question 104 (2006) , Question 110 (2006)
|
Maintained by Fred Barnes, last modified Thu May 8 12:58:00 2014 |
