WARNING: This is the _old_ Lustre wiki, and it is in the process of being retired. The information found here is all likely to be out of date. Please search the new wiki for more up to date information.
Architecture - Client Cleanup: Difference between revisions
From Obsolete Lustre Wiki
Jump to navigationJump to search
m (moved QAS Client Cleanup to Architecture - Client Cleanup) |
|||
Line 135: | Line 135: | ||
# Re-use as much existing code as possible | # Re-use as much existing code as possible | ||
# Quality | # Quality | ||
Revision as of 15:36, 18 January 2010
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
- reduce bugs
- SNS
- peer-to-peer traffic of client data caches
- full parallelism
- concurrent I/O to one file
- lock conversion
- extremely wide striping
- updates of file layouts
Models to consider
current situation |
OSC as a block device |
OSC owns pages |
Implementation Constraints
- Re-use as much existing code as possible
- Quality