0% found this document useful (0 votes)
5 views

Operating Systems Final Lab Presentation

Uploaded by

azan
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
5 views

Operating Systems Final Lab Presentation

Uploaded by

azan
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 18

OPERATIN

G
SYSTEMS Ali Tariq
Azan Ali Kadri
FINAL LAB
OS FINAL LAB

AGENDA
•Brief about previous implementations
•Development
•Synchronization primitives
•Testing and debugging

30/12/2022 2
OS FINAL LAB

Introduction
We created a multi-threaded distributed file
system for this lab. It supports an arbitrary
number of clients who connect via sockets.
Every client can simultaneously do all file
operations on multiple files and the changes
are reflected in real-time to all clients. The
server stores the filesystem and data, the
implementation is abstracted away from the
client.

30/12/2022 3
BRIEF ABOUT
PREVIOUS
IMPLEMENTATIO
NS
First Implementation
• Local, only one client could access the filesystem at one
time.
• Contiguous allocation scheme with extents.
• Directory structure implemented as an n-ary tree of
arbitrary height.
• Open file table.
• Prone to external fragmentation

5
First Implementation
• The user could perform the following operations
• List files in current working directory
• Change current working directory
• Create file/directory
• Move file/directory
• Delete file/directory
• Open/close file
• Write/read to/from file
• Move data within file
• Truncate file to given size
• Print memory map (directory structure along with blocks occupied
by a file)
6
First Implementation
• We placed great importance on making our filesystem
work like any POSIX filesystem.
• The user could traverse the filesystem just like any
POSIX filesystem (using cd).
• The user could create files/directories in any directory
and there was no limit on the directory structure’s
height.
• The user could also have multiple files open in multiple
modes and could perform all operations on them.

7
8
Second Implementation
• The second implementation was much like the first
except the fact that user operations were written into a
workload file.
• Multiple workload files could be started at the same
time, and they would run concurrently.
• Each workload file was run in a separate thread.
• No synchronization, which led to errors.

9
FINAL
IMPLEMENTATIO
N DEVELOPMENT
Development
• Clients connect to the server via sockets after specifying
ip of server
• Each client is assigned a thread to execute their
requests
• They identify themselves with a name upon joining
• Their session lasts until they quit
• They issue commands to the server which performs the
operations

11
Development
• Multiple sessions are synchronized, and the filesystem
maintains consistency
• All functionality of previous implementations is present
and available to every client
• Open files table maintains record of which clients have
a certain file open

12
SYNCHRONIZATION
AND IMPLEMENTATION
DETAILS
Implementation Details
• Multiple clients can have a file open in read mode.
• A file can be opened in write mode by one client at a
time.
• If a file is open in write mode by a client, another client
requesting to open it in write mode has to wait until the
other client closes the file.
• We chose this implementation to overcome the problem
of a file being updated while its being read or multiple
concurrent writes to a file.

14
Synchronization Primitives
• We used a mutex to lock the open file table while a file
is being opened.
• For synchronization, each file has a shared mutex.
• Shared mutex allows multiple threads to acquire a
shared lock on a resource and only one thread to
acquire an exclusive lock on a resource.
• Readers acquire shared locks on files, while writers
acquire exclusive locks on files.

15
16

TESTING AND
DEBUGGING
Testing and Debugging
• As expected, multiple issues came up as soon as we
implemented multithreading.
• Extensive debugging was done to ensure that the file
system was working as it should and that the data
maintains consistency
• Extensively used gdb to debug problems arising from
multithreading

17
30/12/2022 18

OS FINAL LAB

THANK YOU

Azan Ali Kadri


355295
[email protected]
github.com/aznszn

Ali Tariq
343281
[email protected]
github.com/valkrypton

You might also like