Lustre Project List - Revision history

Adilger: Remove obsolete projects

2013-05-09T16:25:14Z

Remove obsolete projects

@@ Line 18: / Line 18: @@
 |[https://bugzilla.lustre.org/show_bug.cgi?id=20731 20731]
 |<small>Clean up Linux IOC numbering to properly use "size" field so that mixed 32- and 64-bit kernel/userspace ioctls work correctly.  Attention needs to be paid to maintaining userspace compatibility for a number of releases, so the old ioctl() numbers cannot simply be removed.</small>
 |-
 |Improve testing Efficiency
@@ Line 44: / Line 38: @@
 |[https://bugzilla.lustre.org/show_bug.cgi?id=21524 21524]
 |<small>Remove Lustre kernel patches to allow Lustre servers to be more easily ported to new kernels, and to be built against vendor kernels without changing the vendor kernel RPMs.  There are a number of different patches, each one needs to use equivalent functionality which already exists in the kernel, or work to get the patch accepted upstream.  See also ldiskfs patch removal</small>
 |-
 |fallocate() API
@@ Line 80: / Line 68: @@
+|
 |<small>Fix client to work well under memory pressure, to avoid deadlocks during allocation and be able to continue processing RPCs, reduce caches, free memory.  This is a prerequisite for swap-on-Lustre.</small>
 |-
 |Client subdirectory mounts
@@ Line 134: / Line 104: @@
 |[https://bugzilla.lustre.org/show_bug.cgi?id=22849 22849]
 |<small>For protocol correctness, and improved performance, it would be desirable for all RPCs that are done with a client lock held to send the lock handle along with the request.  For OST requests this means all read, write, truncate operations (unless "lockless") should include a lock handle.  This allows the OST to validate the request is being done by a client that holds the correct locks, and allows lockh->lock->object lookups to avoid OI or inode lookups in most cases.</small>
 |-
 |Simplified Interoperability
@@ Line 164: / Line 122: @@
 |[https://bugzilla.lustre.org/show_bug.cgi?id=18547 18547]
 |<small>Allow MDS/OSS to determine if client can legitimately replay an RPC, by digitally signing it at processing time and verifying the signature at replay time.</small>
 |-
 |Lustre Block Device
@@ Line 194: / Line 146: @@
 |[https://bugzilla.lustre.org/show_bug.cgi?id=17845 17845]
 |<small>Bulk metadata readdir/stat interface to speed up "ls -l" operations.  Send back requested inode attributes for all directory entries as part of the extended dirent data.  Integrate with any proposed API for this on the client.  Needs Large Readdir RPCs to be efficient over the wire, since more data will be returned for every entry.</small>
 |-
 |Small file IO aggregation

Adilger: add mdd-survey link

2012-01-10T12:24:27Z

add mdd-survey link

← Older revision		Revision as of 05:24, 10 January 2012
Line 48:		Line 48:
	\|3		\|3
	\|obdfilter-survey, mdd, benchmarking		\|obdfilter-survey, mdd, benchmarking
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=21658 21658]		\|[https://bugzilla.lustre.org/show_bug.cgi?id=21658 21658] [http://jira.whamcloud.com/browse/LU-633 LU-633] (finished)
	\|<small>Add a low-level metadata unit test to allow measuring performance of the metadata stack without having connected clients, similar and/or integrated to the obdfilter survey (echo client, echo server).</small>		\|<small>Add a low-level metadata unit test to allow measuring performance of the metadata stack without having connected clients, similar and/or integrated to the obdfilter survey (echo client, echo server).</small>
	\|-		\|-

Adilger: /* List of Lustre Features and Projects */ update status of some finished projects

2012-01-09T23:22:28Z

List of Lustre Features and Projects: update status of some finished projects

← Older revision		Revision as of 16:22, 9 January 2012
Line 22:		Line 22:
	\|3		\|3
	\|RPC, OST		\|RPC, OST
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=20128 20128] [http://jira.whamcloud.com/browse/LU-16 LU-16] (~~work in progress~~)		\|[https://bugzilla.lustre.org/show_bug.cgi?id=20128 20128] [http://jira.whamcloud.com/browse/LU-16 LU-16] (finished)
	\|<small>Support objects larger than 2TB in size. Currently the client assumes that the largest possible object size is 2TB, but this limit should be returned from the OST at connect time.</small>		\|<small>Support objects larger than 2TB in size. Currently the client assumes that the largest possible object size is 2TB, but this limit should be returned from the OST at connect time.</small>
	\|-		\|-
Line 84:		Line 84:
	\|4		\|4
	\|MDS, RPC		\|MDS, RPC
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=17833 17833] [http://jira.whamcloud.com/browse/LU-5 LU-5] (~~work in progress~~)		\|[https://bugzilla.lustre.org/show_bug.cgi?id=17833 17833] [http://jira.whamcloud.com/browse/LU-5 LU-5] (finished)
	\|<small>Read directory pages in large chunks instead of the current page-at-a-time reads from the client. This will improve readdir performance somewhat, and reduce load on the MDS. It is expected to be significant over WAN high-latency links.</small>		\|<small>Read directory pages in large chunks instead of the current page-at-a-time reads from the client. This will improve readdir performance somewhat, and reduce load on the MDS. It is expected to be significant over WAN high-latency links.</small>
	\|-		\|-
Line 90:		Line 90:
	\|4		\|4
	\|ldiskfs		\|ldiskfs
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=24268 24268]		\|[https://bugzilla.lustre.org/show_bug.cgi?id=24268 24268] [http://jira.whamcloud.com/browse/LU-80 LU-80] (finished)
	\|<small>Finish off the large EA handling in ldiskfs, and get this code accepted upstream.</small>		\|<small>Finish off the large EA handling in ldiskfs, and get this code accepted upstream.</small>
	\|-		\|-
Line 96:		Line 96:
	\|4		\|4
	\|ldiskfs, obdfilter		\|ldiskfs, obdfilter
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=20063 20063] [http://jira.whamcloud.com/browse/LU-136 LU-136] (~~work in progress~~)		\|[https://bugzilla.lustre.org/show_bug.cgi?id=20063 20063] [http://jira.whamcloud.com/browse/LU-136 LU-136] (finished)
	\|<small>Single OST sizes larger than 16TB. This is largely supported in newer ext4 filesystems (e.g. RHEL5.4, RHEL6), but thorough testing and some bug fixing work may be needed in obdfilter (1.8, 2.0) or OFD (2.x), and other work may be needed in client (all versions).</small>		\|<small>Single OST sizes larger than 16TB. This is largely supported in newer ext4 filesystems (e.g. RHEL5.4, RHEL6), but thorough testing and some bug fixing work may be needed in obdfilter (1.8, 2.0) or OFD (2.x), and other work may be needed in client (all versions).</small>
	\|-		\|-
Line 138:		Line 138:
	\|5		\|5
	\|VFS, DLM		\|VFS, DLM
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=18526 18526] [http://jira.whamcloud.com/browse/ORNL-6 ORNL-6] (~~work in progress~~)		\|[https://bugzilla.lustre.org/show_bug.cgi?id=18526 18526] [http://jira.whamcloud.com/browse/ORNL-6 ORNL-6] (finished)
	\|<small>Enhancement of current statahead to do object glimpse asynchronously once inode stathead has returned layout information. Preferred solution is readdir+ or SOM, but this could help in the short term, and would still be useful for open files and does not affect the network protocol so could be removed when those features are available. Could potentially be extended to do object readahead instead of simply a size glimpse if a lookup-stat-read pattern was detected.</small>		\|<small>Enhancement of current statahead to do object glimpse asynchronously once inode stathead has returned layout information. Preferred solution is readdir+ or SOM, but this could help in the short term, and would still be useful for open files and does not affect the network protocol so could be removed when those features are available. Could potentially be extended to do object readahead instead of simply a size glimpse if a lookup-stat-read pattern was detected.</small>
	\|-		\|-
Line 144:		Line 144:
	\|6		\|6
	\|recovery, RPC		\|recovery, RPC
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=18767 18767] [http://jira.whamcloud.com/browse/LU-19 LU-19] (~~work in progress~~)		\|[https://bugzilla.lustre.org/show_bug.cgi?id=18767 18767] [http://jira.whamcloud.com/browse/LU-19 LU-19] (finished)
	\|<small>Reduce recovery time by having the server notify clients after recovery has completed instead of waiting for the client to timeout the RPC before it begins recovery.</small>		\|<small>Reduce recovery time by having the server notify clients after recovery has completed instead of waiting for the client to timeout the RPC before it begins recovery.</small>
	\|-		\|-
Line 157:		Line 157:
	\|MDS, LOV		\|MDS, LOV
	\|		\|
	\|<small>Improve OST pools support to allow mandatory OST enforcement (i.e. ~~ACLs~~ to ~~only allow~~ specific users to access certain pools, including the default "all OSTs" pool), more complex policy specification (e.g. select a fallback pool on ENOSPC). Allow default initial file placement policies (e.g., server pool, stripe width) to be defined based on cluster membership (NID, UID, GID) and file parameters (name, extension, etc).</small>		\|<small>Improve OST pools support to allow mandatory OST enforcement (i.e. quotas to limit (or deny) specific users to access certain pools, including the default "all OSTs" pool), more complex policy specification (e.g. select a fallback pool on ENOSPC). Allow default initial file placement policies (e.g., server pool, stripe width) to be defined based on cluster membership (NID, UID, GID) and file parameters (name, extension, etc).</small>
	\|-		\|-
	\|Replay Signatures		\|Replay Signatures
Line 168:		Line 168:
	\|6		\|6
	\|RPC, OST, benchmarking		\|RPC, OST, benchmarking
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=13634 13634]		\|[https://bugzilla.lustre.org/show_bug.cgi?id=13634 13634] [http://jira.whamcloud.com/browse/LU-938 LU-938] (work in progress)
	\|<small>Order IO (and possibly metadata) requests by client, file offset, priority, etc in order to improve overall back-end efficiency and/or provide QOS to clients. Dynamically change the number of RPCs in flight for each client to balance the RPC traffic at the server. Previous research done by Sun shows this can significantly improve overall performance.</small>		\|<small>Order IO (and possibly metadata) requests by client, file offset, priority, etc in order to improve overall back-end efficiency and/or provide QOS to clients. Dynamically change the number of RPCs in flight for each client to balance the RPC traffic at the server. Previous research done by Sun shows this can significantly improve overall performance.</small>
	\|-		\|-

Adilger: /* List of Lustre Features and Projects */

2011-05-21T20:09:47Z

List of Lustre Features and Projects

← Older revision		Revision as of 13:09, 21 May 2011
Line 22:		Line 22:
	\|3		\|3
	\|RPC, OST		\|RPC, OST
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=20128 20128]		\|[https://bugzilla.lustre.org/show_bug.cgi?id=20128 20128] [http://jira.whamcloud.com/browse/LU-16 LU-16] (work in progress)
	[http://jira.whamcloud.com/browse/LU-16 LU-16] (work in progress)
	\|<small>Support objects larger than 2TB in size. Currently the client assumes that the largest possible object size is 2TB, but this limit should be returned from the OST at connect time.</small>		\|<small>Support objects larger than 2TB in size. Currently the client assumes that the largest possible object size is 2TB, but this limit should be returned from the OST at connect time.</small>
	\|-		\|-
Line 61:		Line 60:
	\|4		\|4
	\|client, MDS		\|client, MDS
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=24217 24217]		\|[https://bugzilla.lustre.org/show_bug.cgi?id=24217 24217] [http://jira.whamcloud.com/browse/LU-18 LU-18] (work in progress)
	[http://jira.whamcloud.com/browse/LU-18 LU-18] (work in progress)
	\|<small>Allow 100k open files per client. Fix client to not store committed open RPCs in the resend list but instead reopen files from the file handles upon recovery (see Simplified Interop) to avoid O(n) behaviour when adding new RPCs to the RPCs-for-recovery list on the client. Fix MDS to store "mfd" in a hash table instead of a linked list to avoid O(n) behaviour when searching for an open file handle. For debugging it would be useful to have a /proc entry on the MDS showing the open FIDs for each client export.</small>		\|<small>Allow 100k open files per client. Fix client to not store committed open RPCs in the resend list but instead reopen files from the file handles upon recovery (see Simplified Interop) to avoid O(n) behaviour when adding new RPCs to the RPCs-for-recovery list on the client. Fix MDS to store "mfd" in a hash table instead of a linked list to avoid O(n) behaviour when searching for an open file handle. For debugging it would be useful to have a /proc entry on the MDS showing the open FIDs for each client export.</small>
	\|-		\|-
Line 86:		Line 84:
	\|4		\|4
	\|MDS, RPC		\|MDS, RPC
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=17833 17833]		\|[https://bugzilla.lustre.org/show_bug.cgi?id=17833 17833] [http://jira.whamcloud.com/browse/LU-5 LU-5] (work in progress)
	[http://jira.whamcloud.com/browse/LU-5 LU-5] (work in progress)
	\|<small>Read directory pages in large chunks instead of the current page-at-a-time reads from the client. This will improve readdir performance somewhat, and reduce load on the MDS. It is expected to be significant over WAN high-latency links.</small>		\|<small>Read directory pages in large chunks instead of the current page-at-a-time reads from the client. This will improve readdir performance somewhat, and reduce load on the MDS. It is expected to be significant over WAN high-latency links.</small>
	\|-		\|-
Line 99:		Line 96:
	\|4		\|4
	\|ldiskfs, obdfilter		\|ldiskfs, obdfilter
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=20063 20063]		\|[https://bugzilla.lustre.org/show_bug.cgi?id=20063 20063] [http://jira.whamcloud.com/browse/LU-136 LU-136] (work in progress)
	[http://jira.whamcloud.com/browse/LU-136 LU-136] work in progress
	\|<small>Single OST sizes larger than 16TB. This is largely supported in newer ext4 filesystems (e.g. RHEL5.4, RHEL6), but thorough testing and some bug fixing work may be needed in obdfilter (1.8, 2.0) or OFD (2.x), and other work may be needed in client (all versions).</small>		\|<small>Single OST sizes larger than 16TB. This is largely supported in newer ext4 filesystems (e.g. RHEL5.4, RHEL6), but thorough testing and some bug fixing work may be needed in obdfilter (1.8, 2.0) or OFD (2.x), and other work may be needed in client (all versions).</small>
	\|-		\|-
Line 142:		Line 138:
	\|5		\|5
	\|VFS, DLM		\|VFS, DLM
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=18526 18526] work in progress		\|[https://bugzilla.lustre.org/show_bug.cgi?id=18526 18526] [http://jira.whamcloud.com/browse/ORNL-6 ORNL-6] (work in progress)
	\|<small>Enhancement of current statahead to do object glimpse asynchronously once inode stathead has returned layout information. Preferred solution is readdir+ or SOM, but this could help in the short term, and would still be useful for open files and does not affect the network protocol so could be removed when those features are available. Could potentially be extended to do object readahead instead of simply a size glimpse if a lookup-stat-read pattern was detected.</small>		\|<small>Enhancement of current statahead to do object glimpse asynchronously once inode stathead has returned layout information. Preferred solution is readdir+ or SOM, but this could help in the short term, and would still be useful for open files and does not affect the network protocol so could be removed when those features are available. Could potentially be extended to do object readahead instead of simply a size glimpse if a lookup-stat-read pattern was detected.</small>
	\|-		\|-
Line 148:		Line 144:
	\|6		\|6
	\|recovery, RPC		\|recovery, RPC
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=18767 18767]		\|[https://bugzilla.lustre.org/show_bug.cgi?id=18767 18767] [http://jira.whamcloud.com/browse/LU-19 LU-19] (work in progress)
	[http://jira.whamcloud.com/browse/LU-19 LU-19] work in progress
	\|<small>Reduce recovery time by having the server notify clients after recovery has completed instead of waiting for the client to timeout the RPC before it begins recovery.</small>		\|<small>Reduce recovery time by having the server notify clients after recovery has completed instead of waiting for the client to timeout the RPC before it begins recovery.</small>
	\|-		\|-

Adilger: /* List of Lustre Features and Projects */

2011-05-21T20:04:00Z

List of Lustre Features and Projects

← Older revision		Revision as of 13:04, 21 May 2011
Line 23:		Line 23:
	\|RPC, OST		\|RPC, OST
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=20128 20128]		\|[https://bugzilla.lustre.org/show_bug.cgi?id=20128 20128]
	\|[http://jira.whamcloud.com/browse/LU-16 LU-16] (work in progress)		[http://jira.whamcloud.com/browse/LU-16 LU-16] (work in progress)
	\|<small>Support objects larger than 2TB in size. Currently the client assumes that the largest possible object size is 2TB, but this limit should be returned from the OST at connect time.</small>		\|<small>Support objects larger than 2TB in size. Currently the client assumes that the largest possible object size is 2TB, but this limit should be returned from the OST at connect time.</small>
	\|-		\|-
Line 62:		Line 62:
	\|client, MDS		\|client, MDS
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=24217 24217]		\|[https://bugzilla.lustre.org/show_bug.cgi?id=24217 24217]
	\|[http://jira.whamcloud.com/browse/LU-18 LU-18] (work in progress)		[http://jira.whamcloud.com/browse/LU-18 LU-18] (work in progress)
	\|<small>Allow 100k open files per client. Fix client to not store committed open RPCs in the resend list but instead reopen files from the file handles upon recovery (see Simplified Interop) to avoid O(n) behaviour when adding new RPCs to the RPCs-for-recovery list on the client. Fix MDS to store "mfd" in a hash table instead of a linked list to avoid O(n) behaviour when searching for an open file handle. For debugging it would be useful to have a /proc entry on the MDS showing the open FIDs for each client export.</small>		\|<small>Allow 100k open files per client. Fix client to not store committed open RPCs in the resend list but instead reopen files from the file handles upon recovery (see Simplified Interop) to avoid O(n) behaviour when adding new RPCs to the RPCs-for-recovery list on the client. Fix MDS to store "mfd" in a hash table instead of a linked list to avoid O(n) behaviour when searching for an open file handle. For debugging it would be useful to have a /proc entry on the MDS showing the open FIDs for each client export.</small>
	\|-		\|-
Line 87:		Line 87:
	\|MDS, RPC		\|MDS, RPC
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=17833 17833]		\|[https://bugzilla.lustre.org/show_bug.cgi?id=17833 17833]
	\|[http://jira.whamcloud.com/browse/LU-5 LU-5] (work in progress)		[http://jira.whamcloud.com/browse/LU-5 LU-5] (work in progress)
	\|<small>Read directory pages in large chunks instead of the current page-at-a-time reads from the client. This will improve readdir performance somewhat, and reduce load on the MDS. It is expected to be significant over WAN high-latency links.</small>		\|<small>Read directory pages in large chunks instead of the current page-at-a-time reads from the client. This will improve readdir performance somewhat, and reduce load on the MDS. It is expected to be significant over WAN high-latency links.</small>
	\|-		\|-
Line 100:		Line 100:
	\|ldiskfs, obdfilter		\|ldiskfs, obdfilter
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=20063 20063]		\|[https://bugzilla.lustre.org/show_bug.cgi?id=20063 20063]
	\|[http://jira.whamcloud.com/browse/LU-136 LU-136] work in progress		[http://jira.whamcloud.com/browse/LU-136 LU-136] work in progress
	\|<small>Single OST sizes larger than 16TB. This is largely supported in newer ext4 filesystems (e.g. RHEL5.4, RHEL6), but thorough testing and some bug fixing work may be needed in obdfilter (1.8, 2.0) or OFD (2.x), and other work may be needed in client (all versions).</small>		\|<small>Single OST sizes larger than 16TB. This is largely supported in newer ext4 filesystems (e.g. RHEL5.4, RHEL6), but thorough testing and some bug fixing work may be needed in obdfilter (1.8, 2.0) or OFD (2.x), and other work may be needed in client (all versions).</small>
	\|-		\|-
Line 149:		Line 149:
	\|recovery, RPC		\|recovery, RPC
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=18767 18767]		\|[https://bugzilla.lustre.org/show_bug.cgi?id=18767 18767]
	\|[http://jira.whamcloud.com/browse/LU-19 LU-19] work in progress		[http://jira.whamcloud.com/browse/LU-19 LU-19] work in progress
	\|<small>Reduce recovery time by having the server notify clients after recovery has completed instead of waiting for the client to timeout the RPC before it begins recovery.</small>		\|<small>Reduce recovery time by having the server notify clients after recovery has completed instead of waiting for the client to timeout the RPC before it begins recovery.</small>
	\|-		\|-

Adilger at 20:02, 21 May 2011

2011-05-21T20:02:52Z

← Older revision		Revision as of 13:02, 21 May 2011
Line 22:		Line 22:
	\|3		\|3
	\|RPC, OST		\|RPC, OST
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=20128 20128] (work in progress)		\|[https://bugzilla.lustre.org/show_bug.cgi?id=20128 20128]
			\|[http://jira.whamcloud.com/browse/LU-16 LU-16] (work in progress)
	\|<small>Support objects larger than 2TB in size. Currently the client assumes that the largest possible object size is 2TB, but this limit should be returned from the OST at connect time.</small>		\|<small>Support objects larger than 2TB in size. Currently the client assumes that the largest possible object size is 2TB, but this limit should be returned from the OST at connect time.</small>
	\|-		\|-
Line 60:		Line 61:
	\|4		\|4
	\|client, MDS		\|client, MDS
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=24217 24217] (work in progress)		\|[https://bugzilla.lustre.org/show_bug.cgi?id=24217 24217]
			\|[http://jira.whamcloud.com/browse/LU-18 LU-18] (work in progress)
	\|<small>Allow 100k open files per client. Fix client to not store committed open RPCs in the resend list but instead reopen files from the file handles upon recovery (see Simplified Interop) to avoid O(n) behaviour when adding new RPCs to the RPCs-for-recovery list on the client. Fix MDS to store "mfd" in a hash table instead of a linked list to avoid O(n) behaviour when searching for an open file handle. For debugging it would be useful to have a /proc entry on the MDS showing the open FIDs for each client export.</small>		\|<small>Allow 100k open files per client. Fix client to not store committed open RPCs in the resend list but instead reopen files from the file handles upon recovery (see Simplified Interop) to avoid O(n) behaviour when adding new RPCs to the RPCs-for-recovery list on the client. Fix MDS to store "mfd" in a hash table instead of a linked list to avoid O(n) behaviour when searching for an open file handle. For debugging it would be useful to have a /proc entry on the MDS showing the open FIDs for each client export.</small>
	\|-		\|-
Line 84:		Line 86:
	\|4		\|4
	\|MDS, RPC		\|MDS, RPC
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=17833 17833] (work in progress)		\|[https://bugzilla.lustre.org/show_bug.cgi?id=17833 17833]
			\|[http://jira.whamcloud.com/browse/LU-5 LU-5] (work in progress)
	\|<small>Read directory pages in large chunks instead of the current page-at-a-time reads from the client. This will improve readdir performance somewhat, and reduce load on the MDS. It is expected to be significant over WAN high-latency links.</small>		\|<small>Read directory pages in large chunks instead of the current page-at-a-time reads from the client. This will improve readdir performance somewhat, and reduce load on the MDS. It is expected to be significant over WAN high-latency links.</small>
	\|-		\|-
Line 97:		Line 100:
	\|ldiskfs, obdfilter		\|ldiskfs, obdfilter
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=20063 20063]		\|[https://bugzilla.lustre.org/show_bug.cgi?id=20063 20063]
			\|[http://jira.whamcloud.com/browse/LU-136 LU-136] work in progress
	\|<small>Single OST sizes larger than 16TB. This is largely supported in newer ext4 filesystems (e.g. RHEL5.4, RHEL6), but thorough testing and some bug fixing work may be needed in obdfilter (1.8, 2.0) or OFD (2.x), and other work may be needed in client (all versions).</small>		\|<small>Single OST sizes larger than 16TB. This is largely supported in newer ext4 filesystems (e.g. RHEL5.4, RHEL6), but thorough testing and some bug fixing work may be needed in obdfilter (1.8, 2.0) or OFD (2.x), and other work may be needed in client (all versions).</small>
	\|-		\|-
Line 138:		Line 142:
	\|5		\|5
	\|VFS, DLM		\|VFS, DLM
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=18526 18526]		\|[https://bugzilla.lustre.org/show_bug.cgi?id=18526 18526] work in progress
	\|<small>Enhancement of current statahead to do object glimpse asynchronously once inode stathead has returned layout information. Preferred solution is readdir+ or SOM, but this could help in the short term, and would still be useful for open files and does not affect the network protocol so could be removed when those features are available. Could potentially be extended to do object readahead instead of simply a size glimpse if a lookup-stat-read pattern was detected.</small>		\|<small>Enhancement of current statahead to do object glimpse asynchronously once inode stathead has returned layout information. Preferred solution is readdir+ or SOM, but this could help in the short term, and would still be useful for open files and does not affect the network protocol so could be removed when those features are available. Could potentially be extended to do object readahead instead of simply a size glimpse if a lookup-stat-read pattern was detected.</small>
	\|-		\|-
Line 145:		Line 149:
	\|recovery, RPC		\|recovery, RPC
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=18767 18767]		\|[https://bugzilla.lustre.org/show_bug.cgi?id=18767 18767]
			\|[http://jira.whamcloud.com/browse/LU-19 LU-19] work in progress
	\|<small>Reduce recovery time by having the server notify clients after recovery has completed instead of waiting for the client to timeout the RPC before it begins recovery.</small>		\|<small>Reduce recovery time by having the server notify clients after recovery has completed instead of waiting for the client to timeout the RPC before it begins recovery.</small>
	\|-		\|-

Adilger: /* List of Lustre Features and Projects */ add default OST pools

2010-12-10T07:28:31Z

List of Lustre Features and Projects: add default OST pools

← Older revision		Revision as of 00:28, 10 December 2010
Line 62:		Line 62:
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=24217 24217] (work in progress)		\|[https://bugzilla.lustre.org/show_bug.cgi?id=24217 24217] (work in progress)
	\|<small>Allow 100k open files per client. Fix client to not store committed open RPCs in the resend list but instead reopen files from the file handles upon recovery (see Simplified Interop) to avoid O(n) behaviour when adding new RPCs to the RPCs-for-recovery list on the client. Fix MDS to store "mfd" in a hash table instead of a linked list to avoid O(n) behaviour when searching for an open file handle. For debugging it would be useful to have a /proc entry on the MDS showing the open FIDs for each client export.</small>		\|<small>Allow 100k open files per client. Fix client to not store committed open RPCs in the resend list but instead reopen files from the file handles upon recovery (see Simplified Interop) to avoid O(n) behaviour when adding new RPCs to the RPCs-for-recovery list on the client. Fix MDS to store "mfd" in a hash table instead of a linked list to avoid O(n) behaviour when searching for an open file handle. For debugging it would be useful to have a /proc entry on the MDS showing the open FIDs for each client export.</small>
			\|-
			\|Allow default OST pool
			\|4
			\|MDS, LOV
			\|[https://bugzilla.lustre.org/show_bug.cgi?id=24314 24314]
			\|<small>Allow a filesystem-wide default OST pool to be specified. Currently, it is possible to set the default stripe count, size, index on a filesystem with "lfs setstripe" on the filesystem root, but the OST pool name is ignored. There is no other mechanism to specify default the OST pool for all new files in the filesystem, if no pool is specified. This would be useful for WAN or other heterogeneous OST configurations.</small>
	\|-		\|-
	\|Error message improvements		\|Error message improvements

Adilger: /* List of Lustre Features and Projects */ add WIP status to a few projects

2010-12-07T22:23:14Z

List of Lustre Features and Projects: add WIP status to a few projects

← Older revision		Revision as of 15:23, 7 December 2010
Line 22:		Line 22:
	\|3		\|3
	\|RPC, OST		\|RPC, OST
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=20128 20128]		\|[https://bugzilla.lustre.org/show_bug.cgi?id=20128 20128] (work in progress)
	\|<small>Support objects larger than 2TB in size. Currently the client assumes that the largest possible object size is 2TB, but this limit should be returned from the OST at connect time.</small>		\|<small>Support objects larger than 2TB in size. Currently the client assumes that the largest possible object size is 2TB, but this limit should be returned from the OST at connect time.</small>
	\|-		\|-
Line 60:		Line 60:
	\|4		\|4
	\|client, MDS		\|client, MDS
	\|		\|[https://bugzilla.lustre.org/show_bug.cgi?id=24217 24217] (work in progress)
	\|<small>Allow 100k open files per client. Fix client to not store committed open RPCs in the resend list but instead reopen files from the file handles upon recovery (see Simplified Interop) to avoid O(n) behaviour when adding new RPCs to the RPCs-for-recovery list on the client. Fix MDS to store "mfd" in a hash table instead of a linked list to avoid O(n) behaviour when searching for an open file handle. For debugging it would be useful to have a /proc entry on the MDS showing the open FIDs for each client export.</small>		\|<small>Allow 100k open files per client. Fix client to not store committed open RPCs in the resend list but instead reopen files from the file handles upon recovery (see Simplified Interop) to avoid O(n) behaviour when adding new RPCs to the RPCs-for-recovery list on the client. Fix MDS to store "mfd" in a hash table instead of a linked list to avoid O(n) behaviour when searching for an open file handle. For debugging it would be useful to have a /proc entry on the MDS showing the open FIDs for each client export.</small>
	\|-		\|-
Line 78:		Line 78:
	\|4		\|4
	\|MDS, RPC		\|MDS, RPC
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=17833 17833]		\|[https://bugzilla.lustre.org/show_bug.cgi?id=17833 17833] (work in progress)
	\|<small>Read directory pages in large chunks instead of the current page-at-a-time reads from the client. This will improve readdir performance somewhat, and reduce load on the MDS. It is expected to be significant over WAN high-latency links.</small>		\|<small>Read directory pages in large chunks instead of the current page-at-a-time reads from the client. This will improve readdir performance somewhat, and reduce load on the MDS. It is expected to be significant over WAN high-latency links.</small>
	\|-		\|-
Line 102:		Line 102:
	\|4		\|4
	\|OST		\|OST
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=24128 24128]		\|[https://bugzilla.lustre.org/show_bug.cgi?id=24128 24128] (work in progress)
	\|<small>Allow a new OST to replace a previous OST at the same index, in case of hardware replacement or unrecoverable filesystem corruption.</small>		\|<small>Allow a new OST to replace a previous OST at the same index, in case of hardware replacement or unrecoverable filesystem corruption.</small>
	\|-		\|-

Adilger: add large EA handling

2010-12-03T10:24:00Z

add large EA handling

← Older revision		Revision as of 03:24, 3 December 2010
Line 80:		Line 80:
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=17833 17833]		\|[https://bugzilla.lustre.org/show_bug.cgi?id=17833 17833]
	\|<small>Read directory pages in large chunks instead of the current page-at-a-time reads from the client. This will improve readdir performance somewhat, and reduce load on the MDS. It is expected to be significant over WAN high-latency links.</small>		\|<small>Read directory pages in large chunks instead of the current page-at-a-time reads from the client. This will improve readdir performance somewhat, and reduce load on the MDS. It is expected to be significant over WAN high-latency links.</small>
			\|-
			\|Finish large EA handling for ldiskfs
			\|4
			\|ldiskfs
			\|[https://bugzilla.lustre.org/show_bug.cgi?id=24268 24268]
			\|<small>Finish off the large EA handling in ldiskfs, and get this code accepted upstream.</small>
	\|-		\|-
	\|Over 16TB ldiskfs filesystems		\|Over 16TB ldiskfs filesystems
Line 145:		Line 151:
	\|MDS, LOV		\|MDS, LOV
	\|		\|
	\|<small>Improve OST pools support to allow mandatory OST enforcement (i.e. only allow specific users to access certain pools, including the default "all OSTs" pool), more complex policy specification (e.g. select a fallback pool on ENOSPC). Allow default initial file placement policies (e.g., server pool, stripe width) to be defined based on cluster membership (NID, UID, GID).</small>		\|<small>Improve OST pools support to allow mandatory OST enforcement (i.e. ACLs to only allow specific users to access certain pools, including the default "all OSTs" pool), more complex policy specification (e.g. select a fallback pool on ENOSPC). Allow default initial file placement policies (e.g., server pool, stripe width) to be defined based on cluster membership (NID, UID, GID) and file parameters (name, extension, etc).</small>
	\|-		\|-
	\|Replay Signatures		\|Replay Signatures

Adilger: /* List of Lustre Features and Projects */ add OST replacement

2010-11-10T10:04:52Z

List of Lustre Features and Projects: add OST replacement

← Older revision		Revision as of 03:04, 10 November 2010
Line 92:		Line 92:
	\|[https://bugzilla.lustre.org/show_bug.cgi?id=15267 15276]		\|[https://bugzilla.lustre.org/show_bug.cgi?id=15267 15276]
	\|<small>Mount a subdirectory of a filesystem from the client instead of the root.</small>		\|<small>Mount a subdirectory of a filesystem from the client instead of the root.</small>
			\|-
			\|Online OST replacement
			\|4
			\|OST
			\|[https://bugzilla.lustre.org/show_bug.cgi?id=24128 24128]
			\|<small>Allow a new OST to replace a previous OST at the same index, in case of hardware replacement or unrecoverable filesystem corruption.</small>
	\|-		\|-
	\|Implement a distributed snapshot mechanism		\|Implement a distributed snapshot mechanism