Operating Systems Final Lab Presentation
Operating Systems Final Lab Presentation
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
Ali Tariq
343281
[email protected]
github.com/valkrypton