By Chihung Yu, Zhang Chi

RPC(Remote Procedure Call)

Often times it’s slow to run a service over RPC. One way to tackle this problem is to use asynchronous communication which the client sends multiple requests without waiting for responses from the server side. This technique is also known as pipelining requests.

Problems of Pipelining (performance issue):

(1) Batching: Ask for more data per request

(2) Asynchronous: What if requests depend on each other? In particular, what if there are requests fail? (can be tricky)

As the following graph illustrates

ps: pipelining assumes that the order of responses is trivial to the client since we cannot guarantee that each request will arrive in order due to network routing.

Advantage of pipelining requests: improvement in throughput.

Disadvantages of pipelining requests: race condition.

NFS(network file system) and Security

Inside Linux

Can we support multiple kinds of filesystem?

Yes, FAT, ext4, ext3, etc

Use object oriented programing kernel specifies an interface each filesystem implements that interface. (But c is not object oriented!)

Linux NFS

Process structure

NFS is network file system

As we can see from the above graphical illustration, inside linux kernel it has two parts VFS and NFS. In VFS(virtual file system), “struct task” contains multiple of tasks, and each task(process) has its own file descriptor and each file descriptor point to all related works of that process(open or closed file in struct inode)

The actual code that performs all the operations is inside NFS of linux kernel. Each file in the struct file in VFS layer involves a pointer that point to a struct file_operations struct in the NFS layer. This file_operations struct contains pointers to open(), read() and write()that deal with read, write, and open for that specific file.

Can linux support multiple kinds of file systems? Such as FAT, ext3, ext4, etc.

Yes

NFS  problems + design issues

(1) Lost package->resent request(no no harm done if idempotent)

A: unlink(“foo”) B:link(“ba”,”foo”)

If timeout on requests

Unlink (“foo”) response is lost return ENOENT

We can lose transactions implement via links

If(unlink(“foo”)!=0)

            Error();

Server cashes a list of resent request;

Request “ok” if gets a duplicate from same client

Stateless server:

            Contents of server RAM doesn’t matter

            If server reboot, then clients wait + simple reliability - $ rm file can take a while

fd = open(“foo << server reboot>> read(fd,…)

NFS file handle

Uniquely identifies a file on a server -> NFS protocol uses file handles

Persists if server reboots

Unix: dev_t + ino_t + serial member

            File system inode nth time you have created this inode#

NFS protocol:

            Lookup(dirfh,name)->fh + others

            Create(dirfh,”name),attrs)->fh+attrs

            Mkdir(“,”,”)

            Remove(dirfh,name)->status

            Write(fh,data)->status

Unix file system on wheels

CIFS(windows file system on

Write a NFS

Client                       ------------------------------------Server

Asynchronous write -----------------------------------Stateless server

Speculative read       -----------------------------------fsyncàoften cheat or put logs into flash

Client can cash the data

NFS does all-empt to have close to open consistency

What else can go wrong?

            Power failures                         careful writes on a log

            Network failures                     cache + reply

            Media failures                         (assume:single point of failure)

RAID: redundant array of independent disks

RAID0   concatenation (interleaving striping)

RAID1   mirroring

    …

RAID4     |A| |B| |C| |D| |E|  write to both read from either A^B^C^D^E

RAID5     =RAID4 + striping = + no I/O bottleneck

- Hard to add disks less flexible

What’s the disk failure rate?

Annualized failure rate

AFR of RAID4