Hajutatud failisüsteemide märkmed loengust

Allikas: Lambda

Crucial issues

Locking

  • Process A reads a customer record from a file containing account information, including the customer's account balance and phone number.
  • Process B now reads the same record from the same file so it has its own copy.
  • Process A changes the account balance in its copy of the customer record and writes the record back to the file.
  • Process B, which still has the original stale value for the account balance in its copy of the customer record, updates the account balance and writes the customer record back to the file.
  • Process B has now written its stale account-balance value to the file, causing the changes made by process A to be lost.

See also here

Microsoft Windows uses three distinct mechanisms to manage access to shared files:

  • using share access controls that allow applications to specify whole-file access-sharing for read, write, or delete
  • using byte-range locks to arbitrate read and write access to regions within a single file
  • disallowing executing files from being opened for write or delete access

Unix-like operating systems (including Linux and Apple's OS X) do not normally automatically lock open files or running programs. Several kinds of file-locking mechanisms are available in different flavors of Unix, and many operating systems support more than one kind for compatibility.

Linux locking:

  • flock, lockf, and fcntl.

These functions, while managed by the Linux kernel, are known as advisory locking mechanisms.

  • Any program which doesn't bother checking to see if a lock is in place will never know.
  • The kernel won't stop it from reading or writing the file.
  • There are OS-level locks - in memory only, created with the flock() function
  • There are file-level locks - a lock file is created - they stay around unless the creating application unlinks them.
  • To enable mandatory locking, you must first mount the filesystem with the mand mount option: 
  # mount -oremount,mand /data      
  # mount | grep /data   
  /dev/hda7 on /data type ext3 (rw,mand,noatime)

Distributed FS problem

  • The Andrew File System (AFS) presents an interesting case where file locking fails.
  • If an AFS file is accessible from several different machines simultaneously, then a lock obtained on one machine isn't known to another machine.
  • Therefore, two (or more) users on different machines can lock the same file for exclusive use, and each believes their read/write operations are being done by only their machine, when in fact, both can be writing to the same section of the same file.
  • Therefore, "flock" or "fcntl" fails to actually lock exclusively across machines.
  • The locks are successful on any single machine, therefore the only practical way to deal with simultaneous exclusive write access is to have all users login to the same machine. This can be controlled by requiring access programs or scripts that check that the user is on a specific host.

Detailed materials

Google app engine db access

No SQL: a distributed NoSQL engine

Two ways to access through API:

  • Low-level object storage
  • SQL-like query syntax called "GQL".
Pärit leheküljelt "http://lambda.ee/w/index.php?title=Hajutatud_failisüsteemide_märkmed_loengust&oldid=11943"