Hajutatud failisüsteemide märkmed loengust
- 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.
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.
- 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.
- distributed file systems
- NFS system
- Elion distributed file system by S. Petai
- Google file system
- Google bigtable
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".