Architecture - Client Cleanup

Note: The content on this page reflects the state of design of a Lustre feature at a particular point in time and may contain outdated information.

Use Cases to cover

Description	Semantics
dlm:acquiring lock	actions performed on each layer. Interaction with dlm in the bottom layer.
dlm:releasing lock	actions on every layer.
dlm:maintaining lock lru size	where decision to cancel locks is taken.
dlm:blocking ast	notification of layers
dlm:cancellation ast	actions done at every layer
dlm:glimpse ast	actions done at every layer
dlm:lock conversion	client should be able to convert read lock to write lock without flushing out pages
io:read-ahead	have to be encapsulated into llite layer. Current semantics is to be preserved.
io:kms	current semantics is to be preserved. Kms handing should be encapsulated into llite.
io:read	how layers handle typical read call, including read-ahead.
io:short read	how short read is handled.
io:write	how layers handle typical write call.
io:O_APPEND	write into file descriptor opened with O_APPEND
io:O_SYNC	write into file descriptor opened with O_SYNC
io:O_DIRECT	write into file descriptor opened with O_DIRECT
io:no-lsm	write(2) into object that doesn't yet have objects allocated on ost.
io:lockless	how lockless io fits into model.
io:intents	check that ost intents can be implemented.
io:truncate	how typical truncate case is handled. Paths through vfs, locking. Non-page aligned case.
io:unlink	ost-related part of unlink(2) handling.
io:getattr	parallel rpcs.
io:mixed page size	bug 686.
io:recoverable-errors	bug 11710
io:rpc formation	how/when it is decided that rpc is ready to be sent.
io:epoch closure	size on mds.
io:flock	POSIX locking.
io:abortions due to recovery	(ask Peter for details)
io:attributes	how attribute passing during read and write is handled.
io:migration	interaction between stripe sub-object migration and io.
io:parallel io	running out of cache space for certain osc/oss should not block read/write streaming data to other servers
io:extremely wide striping	scalability of system with large number of oss
io:updates of file layout	client has to keep track of file layout accuracy to accommodate for migration
sns:read-modify-write	how read-modify-write is done (especially, locking).
sns:reconstruct-write	where `old' page is kept.
sns:asynchronous mirroring	how raid1 io is done in parallel.
sns:raidframe compliance	check that sns fits into raidframe model.
sns:caching parity	how parity pages are cached (vm issues).
p2p:read	read call, fetching data from other client.
p2p:read-failure	handle other client failure, fall back to server seed.
p2p:fetch	other client fetches data from this one.
vm:mmap-fault	page fault handling.
vm:mmap-dirty	grants vs. mmap.
vm:mmap-locking	locking for read/write-with-mmapped-buffer case.
vm:grants	how out-of-grant situation is handled. When grant is renewed. How multiple mount points on the same node are handled.
vm:memory pressure	how low memory conditions are handled.
vm:balance_dirty_pages()	response to ->writepages().
vm:pdflush	cleaning old data.
vm:no-cache mode	keep liblustre in mind.
misc:lov-osc on mds	changes on the server side.
misc:local mounts	optimizations for server mounts.
misc:stacking	check that configurations without lov or osc are possible.
misc:join file	data structures for join file.

Business Drivers

1. reduce bugs
2. SNS
3. peer-to-peer traffic of client data caches
4. full parallelism
5. concurrent I/O to one file
6. lock conversion
7. extremely wide striping
8. updates of file layouts

Models to consider

current situation

OSC as a block device

OSC owns pages

Implementation Constraints

1. Re-use as much existing code as possible
2. Quality