Hajutatud failisüsteemide märkmed loengust
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.
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)