Chapter 6
This presentation is the property of its rightful owner.
Sponsored Links
1 / 48

Chapter 6 PowerPoint PPT Presentation


  • 71 Views
  • Uploaded on
  • Presentation posted in: General

Chapter 6. Distributed File Systems. Topics. Review of UNIX Sun NFS VFS architecture caching. Layered Structure. Directory service Mapping: file name  unique file ID Access control File service Mapping: file ID  inode File access Block service Block management Device access.

Download Presentation

Chapter 6

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Chapter 6

Chapter 6

Distributed File Systems


Topics

Topics

  • Review of UNIX

  • Sun NFS

    • VFS architecture

    • caching


Layered structure

Layered Structure

  • Directory service

    • Mapping: file name unique file ID

    • Access control

  • File service

    • Mapping: file ID  inode

    • File access

  • Block service

    • Block management

    • Device access

Directory

File service

Block service


Hierarchical directory systems

Hierarchical Directory Systems

  • A general hierarchy: a tree of directories

User directory

root

directory

directory

directory

file

file

file

directory

directory

directory

file

file

file

file


File system layout

File System Layout

  • Disk is divided up into several partitions

    • Each partition has one file system

  • MBR – master boot record

    • boot the computer & contain the partition table

    • Partition table

      • Starting & ending addresses of each partition

      • One partition is marked as active

  • Within each partition

    • Boot block – first block, a program loads the OS

    • Superblock – key parameters about the file sys.


Implementing files

Implementing Files

  • Key issue: how to keep track of which disk sectors go with which file?

    • E.g., block size= 512B, file size=2014B, so where are these 2014/514=4 blocks on disk?

  • Many methods

    • Contiguous allocation

    • Linked list allocation

    • I-nodes

    • Each one has its own pros and cons


Index nodes i nodes

Index Nodes (i-nodes)

  • An i-node lists the attributes and disk addresses of the file’s blocks

  • Only when a file is open, its i-nodes should be loaded into memory

    • Much smaller than FAT

    • Irrelevant to size of disk

Disk block containing additional disk addresses


Chapter 6

i-node and 3-level index

i-node

4 KB

1

4 KB

1K pointers

12

13

14

1K pointers

15

1K pointers


Managing open files in file service layer

Swappable

per process

Disk-resident

Kernel-resident

0

1

inode

2

3

Parent’s OFT

data

0

System

OFT

(stores

position

pointers)

1

In-core

inode

table

2

Child’s OFT

OFT: Open File Table (one entry per open)

Managing open files in File Service layer

1

1

2


Implementing directories

Implementing Directories

  • Directory system: map the ASCII file name onto the info needed to locate the data

    • Directory entry

  • Where are the attributes stored?

    • In the directory entry (MS-DOS/Windows)

    • In the i-nodes (UNIX)

i-node

DOS/Windows

UNIX


Implementing directories example

Implementing Directories: Example

.

Lnk_cnt=2

Lnk_cnt=1

..

foo

Hello world!

6

6

4

bin

.

..

usr

4

VMUNIX

5

2

vmunix

.

5

local

3

..

foo

6

3

/usr/bin

bin2

8

8


Locate a file usr ast mbox

Block 406 is /usr/ast dir.

Locate A File: /usr/ast/mbox

I-node 6 is for /usr

I-node 26 is for /usr/ast

root

Block 132 is /usr dir.

/usr/ast is in block 406

/usr is in block 132

/usr/ast/mbox is i-node 60

Looking up usr yields i-node 6

/usr/ast is i-node 26


How to share a file

How to Share A File?

  • If directory entry has addresses of blocks

    • How about new appended blocks?

  • Addresses of Disk blocks stored separately

    • UNIX i-node approach

  • Symbolic linking: create a link file containing the path name

Dir A

Dir A

Dir A

Dir B

Dir C

Dir B

Dir C

Dir B

Dir C

i-node

Link file

../Dir C/File1

File 1

File 1

Directory entry contains disk address

File 1

Symbolic linking


Caching

Caching

  • Reserve a set of blocks in main memory as disk sectors cache

    • How cache works?

  • Maintenance of the cache

    • Like page replacement: FIFO, LRU, etc.

Front (LRU)

Rear (MRL)

Hash table


Write important blocks back first

Write Important Blocks Back First

  • Write critical blocks back to disk immediately after they are updated (write-through)

    • Reduce the probability of inconsistency greatly

    • Write-through cache: modified blocks are written back immediately

    • Compared to delayed-write

  • Don’t keep data blocks in memory for too long

    • Force synchronization periodically (per 30 sec)


Block read ahead

Block Read Ahead

  • If a file is read sequentially, read block (k+1) when block k is in used by a process

  • If a file is randomly accessed, read ahead wastes bandwidth

  • Detect the access patterns for open files

  • Switch between read ahead or not according to current pattern

  • Q: how to use it on stateless or stateful servers?


Mapping file systems to physical devices

Mapping file systems to physical devices


Mounting

/

Root

file system

bin etc usr

Mount point

cc date sh passwd getty

/

/dev/sd0g

bin src include

yacc ban awk uts stdio.h

Mounting


Man mount

man mount

Mount attaches a file system to the file system hierarchy at the mount_point, which is the pathname of a directory. If mount_point has any contents prior to the mount operation, these are hidden until the file system is unmounted.

The table of currently mounted file systems can be found by examining the mounted file system information file. This is provided by a file system that is usually mounted on /etc/mnttab.


Nfs architecture

NFS Architecture


Stateless file server

Stateless File Server

  • Robust in the face of failures, but

    • Not all operations are idempotent

      • Like lock operation

    • Longer messages

    • Longer processing time


Transparency

Transparency

  • Location transparency

    • Path name (i.e. full name of file) does not say where the file is located.

  • Location Independence

    • Path name is independent of the server. Hence you can move a file from server to server without changing its name.

    • Have a namespace of files and then have some (dynamically) assigned to certain servers. This namespace would be the same on all machines in the system.

  • Root transparency

    • made up name

    • / is the same on all systems

    • This would ruin some conventions like /tmp


Nfs protocols

NFS Protocols

  • Mounting

    • Analyze the pathname

    • Request & store file handler

    • Static & auto mounting

  • Directory and file access

    • Support most UNIX calls

    • No support for open() and close()


Vfs v node architecture

VFS/v-node Architecture

  • Motivation: share a common file server by an arbitrary collection of clients and servers

    • Require a file-system independent framework for file access

  • v-node (virtual i-node): for every open file in the VFS layer

    • Check if a directory or file is local

    • Contain a pointer pointing to an r-node (remote i-node) in NFS client

  • VFS: represent any file system

    • Well-defined interface

    • One for each file system


Virtual file system

Virtual File System


Chapter 6

v-node

r-node

v_flag

v_count

v_type

v_vfsmountedhere …

v_data

  • Data fields (struct v-node)

  • Methods (struct vnodeops)

v_op

FS-dependent

implementation of vnodeops

(Shared among

Unix vnodes)c

vop_open vop_lookup

vop_read vop_mkdir

vop_getaddr …

Interface

definition

FS-independent part


Vfs implementation

VFS implementation

FS-dependent

data

vfs_data

vfs_next

vfs_fstype

vfs_vnodecoverd …

  • Data fields (struct vfs)

  • Methods (struct vfsops)

vfs_op

vfs_mount vfs_root

vfs_unmount vfs_sync

vfs_statvfs …

FS-dependent

implementation of vfsops

Interface

definition

FS-independent part


Struct vfs instance

Struct vfs instance

  • vfs_data

  • vfs_ops

  • vfs_next:pointer to the next FS mounted

  • vfs_fstype:ufs, nfs, ext2fs, etc.


Mounting1

Mounting

vfs

vfs

Root file

system

Mounted

file system

rootvfs

covers

belongs

to

mounted

here

ROOT

ROOT

/

/

/usr

vnode

vnode

vnode

v-nodes for mounted-on directories are kept in main memory.


Implementation

Implementation

  • Server: export one or more of its directories for access by remote clients

    • /etc/exports file, e.g.,

      /usr/local –access=hostA:hostB

      /usr/bin –ro

  • Client: mount the exported directories

    • Become part of its directory

    • No difference between a local file or a remote file

    • Two clients can communicate by sharing files in their common directories.


Mount a remote file system

Mount A Remote File System

  • Call mount program, specify the remote directory and local mount point.

    • E.g., mount -t msdos /dev/ad0s1 /mnt/windows

    • E.g., mount indus:/usr/src /usr/src

  • Parse the name and find the server

  • Contact the server

  • Receive the file handler

  • Create a v-node for the remote directory in vfs layer

  • Create a r-node in NFS client, pointed by the v-node


Mount 1

Mount (1)

Mounting (part of) a remote file system in NFS.


Mount 2

Mount (2)

Mounting nested directories from multiple servers in NFS.


Automounting 1

Automounting (1)

ps -fe | grep automount


Automounting 2

Automounting (2)

Using symbolic links with automounting.

  • Can also be used with file replication.


Open a remote file

Open A Remote File

  • Parse the file name

    • Get the v-node and r-node of the mounted file system

  • Ask NFS client to open the file

  • Contact server and get the file handler for the opened file

  • NFS client creates an r-node for the file

  • vfs creates a v-node for the file


File attributes 1

File Attributes (1)

Some general mandatory file attributes in NFS.


File attributes 2

File Attributes (2)

Some general recommended file attributes.


Semantics of file sharing 1

Semantics of File Sharing (1)

  • On a single processor, when a read follows a write, the value returned by the read is the value just written.

  • In a distributed system with caching, obsolete values may be returned.


Semantics of file sharing 2

Semantics of File Sharing (2)

Modified session semantics: changes to an open file are initially visible only to the processes on the same machine. Upon closed, the changes are visible to other machines.


Unix semantic

UNIX Semantic

  • Probably Unix doesn't quite do this.

    • If a write is large (several blocks) do seeks for each

    • During a seek, the process sleeps (in the kernel)

    • Another process can be writing a range of blocks that intersects the blocks for the first write.

    • The result could be (depending on disk scheduling) that the result does not have a last write.

  • Perhaps Unix semantics means - A read returns the value stored by the last write providing one exists.


File locking in nfs

File Locking in NFS

More complicated with file replication.


Client caching 1

Client Caching (1)

Q: where to put the cache? a) user space b) kernel space


Client caching 2

Client Caching (2)

Using the NFS version 4 callback mechanism to recall file delegation.


Lease

Lease

  • When a client wants a file, the server gives a lease on it that specifies how long the copy is valid

  • Client renew the lease before it expires

    • No message sent when a lease expires

  • How about client crash?

  • How about server crash?

    • Lease time and reboot time


Cache management algorithms

Cache Management Algorithms


General principles for ds

General Principles for DS

  • Proposed by Satyanarayanan

    • Clients have cycles to burn

    • Cache whenever possible

    • Exploit the usage properties

    • Minimize system-wide knowledge and change

    • Trust the fewest possible entities

    • Batch work where possible


Possible trends

Possible Trends

  • Main memory file system

  • Fiber optic network

    • Effects on cache

  • Mobile users

    • Disconnection

    • Geographic location

  • Multimedia application

    • VOD


  • Login