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 - User Level OSS: Difference between revisions
From Obsolete Lustre Wiki
Jump to navigationJump to search
m (Protected "Architecture - User Level OSS" ([edit=sysop] (indefinite) [move=sysop] (indefinite))) |
No edit summary |
||
| Line 1: | Line 1: | ||
'''''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. | '''''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.'' | ||
== Summary Requirements == | == Summary Requirements == | ||
Latest revision as of 13:25, 22 January 2010
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.
Summary Requirements
| io_cli_fail | if a Lustre client fails, and the OSS has partially executed an IO operation, it leaves the server file system in a reasonable state. |
| io_oss_fail | if an OSS fails, a client will retry to complete partial IO operations and they will complete as if the OSS had not failed |
| io_no_copy | for large IO transfers there will be no copy of data pages as is common in read/write system call implementation. |
| io_double_failure | If the OSS and the client fail, allowing 0's in the file due to truncation is certainly permitted, even the possibility of bad data like in ext3 write back mode is probably acceptable. |
| io_llog_refinement | Ideally with LAID llogging, a more complex method can be introduced that can undo the damage in the double failure case |
