Topic: Final Exam

Description: ???

Created: 2010-04-23 - Whiteboard clarifications from class period
Question 1:

• you have a choice in undoing the process 1 side of copy-on-write. A solution is OK if it doesn't cause an extra page copy.
• The VM structure does not use or provide any physical pages - it's an internal OS structure that describes how pages in the virtual address space should be handled.
• Assume a uniprocessor - fork() should return first to either the parent or the child (either is OK), rather than running both simultaneously. (there's nothing wrong with assuming they both return simultaneously, but it's more complicated)
  
Question 2

• part 1 - "0 to 195" should be "0 to 199"
• part 2:
• each logical write is to a single "chunk" - an aligned 8-block (4KB) extent.
• mapping is in terms of 8-block, 4KB aligned chunks.
• thus, physical reads and writes will all be aligned 4KB chunks
  
Question 3:

• you do not need to include error checks in your description. Thus you can assume that:
• /a and /a/b are directories (no need to return -ENOTDIR)
• the user has appropriate permission (no -EACCES checks)
• and so on...
  
Question 4:

•  part 1 - file ownership is arbitrary. If an assignment of owner, group, and permissions implements the indicated access matrix, it is correct.
• near the bottom of the page:
  "the rule (user=user1, rights=-w-, action=deny) will prevent user1 from writing the file, but will not prevent user1 from writing the file"
  
This makes no sense. It should be:

 "the rule (user=user1, rights=-w-, action=deny) will prevent user1 from writing the file, but will not prevent user1 from reading the file"


-- by Anon.


Created: 2010-04-23 - Question 2, blocks vs. chunks

> In part 1, we are supposed to convert a logical block address into a
> physical disk and its block address.  Are we converting the global
> logical block address into a disk and its chunk (one of 5)?  Or into
> one of the disk's blocks (one of 40)?  Sorry for being unclear on
> this.

You are given a logical block address within the volume, in units of 512-byte blocks, which ranges from 0 to 199 or 159. You convert it to logical block addresses within individual disks which, as you note, range from 0 to 39. The "chunks" only exist hypothetically in the middle of the translation formula.


-- by Anon.


Created: 2010-04-25 - LBA vs. chunk, page fault on SYSCALL

> I have some questions: -- Question 2, Part 1: We need to convert from
> volume LBA to disk LBA and disk#. "Disk LBA" is one of the number in
> the squares (eg for RAID0: from 0 to 24) or the number of row of a
> chunk (i.e. from 0 to 4)? And in general, when we are saying "chunk
> number" is a number from 0 to 4 and disk LBA a number from 0 to 24
> (for RAID0)?

"chunk" is in units of 4096 bytes. LBA is in units of 512 bytes.

>
> -- Question 1: For SYSCALL (eg for SYSCALL fork) should we describe
> how is it perform in terms of page faults, copy-on-write, etc, or are
> we gonna skip this description and assume that vm, pt, etc change as
> you describe in first page?

None of the syscalls reference any addresses other than their own instruction fetch. If there's a page fault on that, it's no different than any other instruction.


-- by Anon.


Created: 2010-04-25 - Question 2 part 3
>
> Question 2, Part 3: Isn't it the same analysis by assuming that the
> sequence of writes are uniformly distributed across the disks instead
> of the volume logical address space?

If I answered that, I might be answering the question for you.


-- by Anon.


Created: 2010-04-25 - Question 1 - fork()
My reply to a fairly complicated question:


'pt' consists of the page directory and any page table pages it points to, all of which serve to map addresses, and the contents of which do not show up in the virtual address space.

To clarify, instead of saying "finding all the writable pages in 'pt' and changing them' I should have said "finding all the writable pages   mapped by 'pt'"  (or "pointed to by 'pt'" or something like that)


-- by Anon.


Created: 2010-04-25 - Question 3 - level of detail?
> I have certain doubts in Q3.
>
> For the sub parts A and B , what kind of answer do you expect because
> it seems to be exactly same as the implementation in HW4. Is that
> what we are supposed to write?

I'm looking for a higher-level description of the steps, showing that you understand them, rather than e.g. a line-by-line debugger trace of the execution. But you're right - I'm asking you to describe something which you've already implemented in code.

>
> For sub-part C, do we have to take into consideration the entire UNIX
>  filesystem or just replace INODE's in the respective places, For
> instance, the superblock in UNIX system ,varies from the one we
> implemented in HW4 ie it does not have the reference. So, do we have
> to take into consideration this structure for part C.

Assume that the superblock (which we've already fetched into memory) contains the block number of the root directory *inode*.


-- by Anon.