[Twg] ORNL priorities for roadmap
David Dillow
dillowda at ornl.gov
Wed Dec 15 22:16:56 UTC 2010
My thoughts on our priorities. In many cases, the priorities in each
category shift a bit depending on expected time to deployment.
1) Metadata scaling!
There are many aspects to this, but this is a big pain point for us.
While we expect to need to move to some form of CMD, using NRS to avoid
blocking all of the MDS threads on one lock will give us much needed
breathing room. Other items of interest include SMP scaling work, RPC
aggregation, and subtree locking. The priorities in this category shift
quite a bit depending on how long it will take to develop them, and how
they lay foundation for future improvements.
ORNL has some work going in this area, but that is a small part of the
puzzle.
2) Failover and recovery time.
It takes far too long for clients to notice failures and connect to the
HA partners. It seems the health network ideas could help this, and
perhaps allow us to run lower timeouts as well.
ORNL has some work going in this area as well.
3) Future expansion/data protection
ldiskfs has done well, but it is expected that a migration to ZFS or
BTRFS is inevitable. Ensuring data integrity from client to platter and
back is going to become a significant issue going forward.
ORNL may be able to contribute to benchmarking and stress testing of the
different backends, but I think OpenSFS will want to contract out the
code review unless a member can contribute the necessary expertise.
4) Scalable management, analytics, etc.
We know we have orphans and missing objects from various bugs
encountered over the life of our production filesystems, so online
filesystem checking is seen as a win to us -- we cannot afford the
downtime to do the offline fscks required.
I like the idea of the dynamic LNET configuration, but it is only truly
useful if we stop requiring a server reboot to change the LNET a client
comes in on -- currently the RPC layer will always talk to a client via
the same LNET with which it first connected to the server.
Being able to quickly purge files and run du without needing elaborate
out-of-band systems will make our admin's life easier.
--
Dave Dillow
National Center for Computational Science
Oak Ridge National Laboratory
(865) 241-6602 office
More information about the Twg
mailing list