Architecture - FIDs on OST - Revision history

Docadmin at 21:09, 22 January 2010

2010-01-22T21:09:39Z

← Older revision		Revision as of 14:09, 22 January 2010
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 ==		== Summary ==

Docadmin: Protected "Architecture - FIDs on OST" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

2010-01-21T19:36:01Z

Protected "Architecture - FIDs on OST" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

← Older revision	Revision as of 12:36, 21 January 2010
(No difference)

Docadmin: /* Summary */

2010-01-18T23:57:29Z

Summary

← Older revision		Revision as of 16:57, 18 January 2010
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.

	== Summary ==		== Summary ==

Docadmin: /* QAS template */

2010-01-14T22:17:54Z

QAS template

← Older revision		Revision as of 15:17, 14 January 2010
Line 88:		Line 88:
	\|-		\|-
	\|}		\|}


	~~[[Category:Architecture\|FIDs_on_OST]]~~

Docadmin: /* Summary */

2010-01-14T22:16:39Z

Summary

← Older revision		Revision as of 15:16, 14 January 2010
Line 3:		Line 3:
	We introduce new fids on OST. Using FIDs to identify objects on OSTs needs to be compatible with the existing object IDs used in current Lustre releases. There are two areas that need to maintain compatibility - the numbering of the objects themselves, and their encoding into RPCs in order to communicate between clients and servers.		We introduce new fids on OST. Using FIDs to identify objects on OSTs needs to be compatible with the existing object IDs used in current Lustre releases. There are two areas that need to maintain compatibility - the numbering of the objects themselves, and their encoding into RPCs in order to communicate between clients and servers.

	In order to avoid FID numbers conflicting with existing objects the old objects are mapped into the reserved IDIF namespace as discussed in [[Architecture - Interoperability fids zfs]], using the ost_idx as part of the IDIF sequence number to disambiguate otherwise identical object numbers on different OSTs.		In order to avoid FID numbers conflicting with existing objects the old objects are mapped into the reserved IDIF namespace as discussed in [[Architecture - Interoperability fids zfs\|Interoperability fids zfs]], using the ost_idx as part of the IDIF sequence number to disambiguate otherwise identical object numbers on different OSTs.

	For network protocol interoperability with existing OSTs and clients the FID numbers must be mapped onto the o_id and o_gr fields.		For network protocol interoperability with existing OSTs and clients the FID numbers must be mapped onto the o_id and o_gr fields.

Docadmin: /* Summary */

2010-01-14T22:16:16Z

Summary

← Older revision		Revision as of 15:16, 14 January 2010
Line 3:		Line 3:
	We introduce new fids on OST. Using FIDs to identify objects on OSTs needs to be compatible with the existing object IDs used in current Lustre releases. There are two areas that need to maintain compatibility - the numbering of the objects themselves, and their encoding into RPCs in order to communicate between clients and servers.		We introduce new fids on OST. Using FIDs to identify objects on OSTs needs to be compatible with the existing object IDs used in current Lustre releases. There are two areas that need to maintain compatibility - the numbering of the objects themselves, and their encoding into RPCs in order to communicate between clients and servers.

	In order to avoid FID numbers conflicting with existing objects the old objects are mapped into the reserved IDIF namespace as discussed in [[Interoperability fids zfs]], using the ost_idx as part of the IDIF sequence number to disambiguate otherwise identical object numbers on different OSTs.		In order to avoid FID numbers conflicting with existing objects the old objects are mapped into the reserved IDIF namespace as discussed in [[Architecture - Interoperability fids zfs]], using the ost_idx as part of the IDIF sequence number to disambiguate otherwise identical object numbers on different OSTs.

	For network protocol interoperability with existing OSTs and clients the FID numbers must be mapped onto the o_id and o_gr fields.		For network protocol interoperability with existing OSTs and clients the FID numbers must be mapped onto the o_id and o_gr fields.

Docadmin: moved FIDs on OST to Architecture - FIDs on OST

2010-01-14T21:54:01Z

moved FIDs on OST to Architecture - FIDs on OST

← Older revision	Revision as of 14:54, 14 January 2010
(No difference)

Docadmin: 1 revision

2010-01-14T21:01:10Z

1 revision

← Older revision	Revision as of 14:01, 14 January 2010
(No difference)

Adilger: /* Summary */

2009-05-01T08:11:47Z

Summary

New page

== Summary ==

We introduce new fids on OST. Using FIDs to identify objects on OSTs needs to be compatible with the existing object IDs used in current Lustre releases. There are two areas that need to maintain compatibility - the numbering of the objects themselves, and their encoding into RPCs in order to communicate between clients and servers.

In order to avoid FID numbers conflicting with existing objects the old objects are mapped into the reserved IDIF namespace as discussed in [[Interoperability fids zfs]], using the ost_idx as part of the IDIF sequence number to disambiguate otherwise identical object numbers on different OSTs.

For network protocol interoperability with existing OSTs and clients the FID numbers must be mapped onto the o_id and o_gr fields.

== Definitions ==

; '''fid''': cluster-wide unique identificator
; '''sequence''': contiguous set of fids, all fids from given sequence belong to single specific node
; '''fld''': persistent sequence to node mapping
; '''object''': OST object used to store user's data (what about internal to OST objects, like last_rcvd?)

== Requirements ==

# any node can generate fids to be used for OST objects
# no orphans after partial recovery
# objects to be created on demand (CROW)
# backward compatibility?

== Use Cases ==

{| cellspacing="0" border="1"
! ID !! Quality Attribute !! Summary
|-
| new sequence
| usability, performance
| client gets sequence from specific OST
|-
| create file
| usability
| create file on MDS with specified objects
|-
| space balance
| usability,performance
| how to distribute objects among OSTs
|-
| file exists
| usability
| create file request finds existing file
|-
| reconnect
| availability
| reconnect after OST failover
|-
| 2.0
| usability
| compatibility mode: MDS talks to OST to get new fids
|-
| 2.x
| usability
| clients talk to OST to get new fids
|-
| orphan
| availability
| server should be able to identify orphan objects
|}

== Quality Attribute Scenarios ==

=== QAS template ===

{|border=1 cellspacing="0"
|-align="left"
|colspan=2|'''Scenario:''' ||
|-align="left"
|colspan=2|'''Business Goals:''' ||
|-align="left"
|colspan=2|'''Relevant QA's:'''||
|-align="left"
|rowspan="6" writing-mode="vertical"|'''details'''
|'''Stimulus source:'''||
|-align="left"
| '''Stimulus:'''||
|-align="left"
|'''Environment:'''||
|-align="left"
|'''Artifact:'''||
|-align="left"
|'''Response:'''||
|-align="left"
|'''Response measure:'''||
|-align="left"
|colspan=2|'''Questions:'''||
|-align="left"
|-
|}

[[Category:Architecture|FIDs_on_OST]]