consistancy_semantics.txt

NOTE: THIS IS OUT OF DATE

Client side design decisions relating to consistency:
--
(IE: "why is the client sending these messages in this order")
=============================================

PVFS_sys_remove()
-----------------
- here's the order:
	-pcache copy/getattr on the parent
	-lookup the item to be removed
	-pcache copy/getattr on the meta handle (get datafiles)
	-check permissions on the meta handle
	-send remove message to the server containing metafile
	-send rmdirent to the meta server
	-send remove messages for each of the data files

We're removing the meta file first to prevent someone coming in and trying to chmod the file before the operation has completed.  This will also cause future lookup operations to fail.  

PVFS_sys_create()
----------------
-here's the order:
	-pcache copy/getattr on the parent
	-check permissions on the parent to ensure writablility
	-does the directory already exist in the dcache?
		-if it is, exit in error.
	-create the metafile
	-create the directory entry corresponding to the meta file
		-if the dirent already exists, remove the meta file; exit.
	-create each data file.
	-setattr on the meta file to store data file handles/permissions/etc.

we're going to assume that most creates will not fail as a result of a file already existing.  if the file already does exist, we'll rollback (send a remove message to the meta server for) the newly created metafile.

--stuff to think about & come back later on:
	2 threads, both know the name of the file, one is in a 
	while(1) { 
		system("chmod 0 filename"); 
		system("chown nobody.nouser filename");
	} 
	loop and the other thread calls:
	creat(filename, 0777).

	==> create is not atomic, we have to send multiple messages on the network, so its possible that someone could try to setattr/remove the metafile before the create operation succeeds.
	Should we add a boolean flag to the metadata "isComplete" or something so that if the file is in the process of being created, we'll know to make any operations block?

PVFS_sys_truncate()
-------------------
-instead of retrieving the size, figuring out which servers need to get truncate messages, we're just sending truncate messages to each server with the physical offset (found from the logical size that is passed in).  it may be the case that someone is doing io on a file, and the size could be changing in the middle of a truncate operation, which could lead to problems making sure everything that is supposed to get truncated is truncated.