Distributed Systems

File Models
 File Models- Introduction

Different File systems use different conceptual models.

• Unstructured and structured files.

• Mutable and Immutable files.
 Structured File

In structured files, the file appears to the file server as

an ordered sequence of records.

Records of different files of the same file system can be
of different sizes.

Record is the smallest unit in structured file.

Read and write operation is performed on set of
records.
 Structured File - Types
Structured files are of two types:

Index Record file:

• Records have one or more key fields.
• Key is used to access the records.
• File is maintained by suitable data structures like hash tables and
indices.

Non-indexed record file:

• File record is accessed by specifying its position within the file .

• EXAMPLE: Fifth record from beginning, second record from the end.
 Unstructured Files

In the unstructured model, file is an unstructured

sequence of data.

There is no substructure known to the file server.

File content is also an uninterpreted sequence of
bytes.

Kernel does not interpret the content or structure
of the file.
 Mutable and Immutable Files

• Mutable and Immutable files are based on the modifiability

criteria.
• A mutable file can be updated or extended. This means
you can change, add or remove elements of a collection.
• Most existing operating systems use the mutable file
model. An update performed on a file overwrites its old
contents to produce the new contents.
• Immutable file:

An immutable file is one that, once created, cannot be
changed. Immutable files are easy to cache across servers
since their contents are guaranteed to remain unchanged.

In the immutable model, rather than updating the same file,
a new version of file is created. Each time a change is
made to the file contents , the old version is retained
unchanged.
 File Accessing Model

Accessing remote files are of two types :

• Remote service model

• Data caching model

 File Accessing Model (contd.)
In Remote service model, the client submits requests
to
server; all processing is done on server. File never
moves from server. Problem is server bottleneck.

In Data Caching Model, it uses locality feature to

reduce network traffic. For open file operation, transfer
entire file to client and for close operation, it transfers
entire file to server.
Client works on the file locally
 Unit of Data Transfer

• Transfer levels are file, block, byte and record.

• The unit of data transfer when a request is satisfied by a
server can be:
• A whole file
• A number of blocks of a file
• A number of bytes
• A number of records.
 Transfer Level : File

• Whole File is moved to the client side or server side

before performing operation.
• It is simple and involves less communication overhead
• Immune to server.
• A client is required to have large storage space.
• If small fraction of a file is required, moving whole
file is wasteful.
 Transfer Level :Block

• File transfer between client and server takes

place in blocks.
• Also called page level transfer model.
• A client is not required to have large storage.
• Used in diskless workstation.
• No need for copying entire file.
• Network traffic overhead
 Transfer Level :Byte

• File transfer between client and server takes place in

bytes

• Flexibility maximized

• Difficult cache management to handle the variable

length data.
 Transfer Level : Record

• File transfer between client and server takes

place in records.

• Handling structured and indexed files.

• More network traffic.

• More overhead to re-construct a file

File-Accessing Models
 File-Sharing Semantics

 Define when modifications of the file data made

by a user are observable by other users.

1. Unix semantics
2. Session Semantics
3. Immutable shared-files semantics
4. Transaction-like semantics
 Unix Semantics

• It enforces an absolute time ordering on all

operations.
• Writes to an open file is visible to other users
of the same open file.
• Centralized systems use UNIX semantics.
 File-Sharing Semantics
Unix Semantics

Absolute Ordering
Client A Append(d)
read

a b a b
a b c a b c a b c d a b c d e a b c d e
a b c
t1 t2 t3 t4 t5 t6
delayed
Append(c) Append(d) read
Client B

Network Delays
 Session Semantics

• Writes to a file by an user is not visible to

other

• Once the file is closed, the changes are visible

only to new sessions
 File-Sharing Semantics
Session Semantics
Client A Client B Client C Server
a b
Open(file) a b
Append(c) a b c
Open(file) a b
Append(d) a b c d

Append(e) a b c d e
Append(x) a b x

Close(file)
Append(y) a b c y
a b c d e
Append(z) a b c d z
Open(file) a b c d e
Close(file)
a b c d z
Append(m) a b c d e m
Close(file)
a b c d e m

Close(file)
 Transaction-like semantics
• All changes occur automatically.
• Begin transaction, perform operations and end transaction.
• Partial modifications made to the shared data by a
transaction will not be visible to other concurrently
executing transaction until the transaction ends.
• The final file content is the same as if all the transactions
were run in some sequential order.
 File-Sharing Semantics
Transaction-Like Semantics
(Concurrency Control)
Backward validation Forward validation
Client A Client B Client C Client D Client A Client B Client C Client D
Trans_start Trans_start
Compare reads with Compare write with
R1 R1 later reads
former writes
R2 R2
Trans_start Trans_start
W3 W3
R4 R1 R4 R1
W5 R2 Trans_start W5 R2 Trans_start
W6 W6
validation R1 validation R1
R4 R4
Commitment W7 R2 Commitment W7 R2
Trans_start Trans_start
Trans_end W9 Trans_end W9
R1 R1
R4 R4
R2 Trans_abort R2
W8 W8
Trans_end R6 Trans_restart R6
R8 R8
W8 W8
Trans_end Trans_end
Trans_abort
Abort itself or conflicting active transactions
Trans_restart
Trans_end

Which validation is better?

 Immutable shared file semantics

• Under this system, when a file is declared as shared by its

creator, it becomes immutable and the name cannot be re-
used for any other resource.
• Hence it becomes read-only, and shared access is simple
• An immutable file has two key properties.
• Its name may not be reused and its contents may not be
altered.
 File-Sharing Semantics
Immutable Shared-Files Semantics

Client A Client B Server

Version
1.0

Tentative Tentative
based on based on
1.0 1.0

Version
1.1

Version conflict
Abort
Depend on each file system.
Version Version
Abortion is simple (later, the client A can 1.2 1.2
Decide to overwrite it with its tentative 1.0
by changing the corresponding directory) Ignore conflict Merge
 Summary
• File model
– Unstructured and structured files
– Mutable and Immutable files

• File accessing model

– Remote service model
– Data caching model

• Unit of data transfer

– File
– Block
– Byte
– Record

• File sharing semantics

– Unix semantics
– Session Semantics
– Immutable shared-files semantics
– Transaction-like semantics