[gpfsug-discuss] GPFS Evaluation List - Please give some comments
Grace Tsai
gtsai at slac.stanford.edu
Wed May 30 20:15:55 BST 2012
Hi,
We are in the process of choosing a permanent file system for our
institution,
GPFS is one of the three candidates. Could someone help me to give
comments or answers to the requests
listed in the following. Basically, I need your help to mark 1 or 0 in
the GPFS column if a feature either
exists or doesnt exist, respectively. Please also add supporting
comments if a feature has
additional info, e.g., 100PB single namespace file system supported, etc.
I answered some of them which I have tested, or got the information
from google or manuals.
User-Visible Features:
-----------------------------
1. Allows a single namespace (UNIX path) of at least 10s of petabytes in
size.
(My answer: Current tested: 4PB)
2. Large number of files supported (specify number) per namespace.
(My answer: 9*10**9)
3. Supports POSIX-like mount points (i.e., looks like NFS)
(My answer: 1)
4. File system supports file level access control lists (ACLs)
(My answer: 1)
5. File system supports directory level ACLs, e.g., like AFS.
(My answer: 1)
6. Disk quotas that users can query.
(My answer: 1)
7. Disk quotas based on UID
(My answer: 1)
8. Disk quotas based on GID
(My answer: 1)
9. Disk quotas based on directory.
10. User-accessible snapshots
Groupadmin-Visible Features
---------------------------------------
1. Group access (capabilities) similar to AFS pts groups.
(My answer: 1)
2. Group access administration (create/delete/modify) that can be
delegated to the groups themselves.
(My answer: 1)
3. High limit (1000s) on the number of users per group
4. High limit (100s) on the number of groups a user can belong to.
(My answer: 1)
5. Nesting groups within groups is permitted.
6. Groups are equal partners with users in terms of access control lists.
7. Group managers can adjust disk quotas
8. Group managers can create/delete/modify user spaces.
9. Group managers can create/delete/modify group spaces.
Sysadmin-Visible Features
-----------------------------------
1. Namespace is expandable and shrinkable without file system downtime.
(My answer: 1)
2. Supports storage tiering (e.g., SSD, SAS, SATA, tape, grid, cloud)
via some type of filtering, without manual user intervention (Data
life-cycle management)
3. User can provide manual "hints" on where to place files based on
usage requirements.
4. Allows resource-configurable logical relocation or actual migration
of data without user downtime (Hardware life-cycle
management/patching/maintenance)
5. Product has been shipping in production for a minimum of 2 years,
nice to have at least 5 years. Must be comfortable with the track record.
(My answer: 1 )
6. Product has at least two commercial companies providing support.
7. Distributed metadata (or equivalent) to remove obvious file system
bottlenecks.
(My Answer: 1)
8. File system supports data integrity checking (e.g., ZFS checksumming)
(My answer: 1)
9. Customized levels of data redundancy at the
file/subdirectory/partition layer, based on user requirements.
Replication. Load-balancing.
10. Management software fully spoorts command line interface (CLI)
10. Management software supports a graphical user interface (GUI)
11. Must run on non-proprietary x86/x64 hardware (Note: this might
eliminate some proprietary solutions that meet every other requirement.)
12. Software provides tools to measure performance and monitor problems.
(My answer: 1)
13. Robust and reliable: file system must recover gracefully from an
unscheduled power outage, and not take forever for fsck.
14. Client code must support RHEL.
(My answer: 1)
15. Client code must support RHEL compatible OS.
(My answer: 1)
16. Client code must support Linux.
(My answer: 1)
17. Client code must support Windows.
(My answer: 1)
18. Affordable
19. Value for the money.
20. Provides native accounting information to support a storage service
model.
21. Ability to change file owner throughout file system (generalized
ability to implement metadata changes)
22. Allows discrete resource allocation in case groups want physical
resource separation, yet still allows central management.
Resource allocation might control bandwidth, LUNx, CPU,
user/subdir/filesystem quotas, etc.
23. Built-in file system compression option
24. Built-in file-level replication option
25. Built-in file system deduplication option
26. Built-in file system encryption option
27. Support VM image movement among storage servers, including moving
entire jobs (hypervisor requirement)
28. Security/authentication of local user to allow access (something
stronger than host-based access)
29. WAN-based file system (e.g., for disaster recover site)
30. Must be able to access filesystem via NFSv3
(My answer: 1)
31. Can perform OPTIONAL file system rebalancing when adding new storage.
32. Protection from accidental, large scale deletions
33. Ability to transfer snapshots among hosts.
34. Ability to promote snapshot to read/write partition
35. Consideration given to number of metadata servers required to
support overall service, and how that affects HA, i.e.,
must be able to support HA on a per namespace basis . (How many MD
servers would we need to keep file service running?)
36. Consideration given to backup and restore capabilities and
compatible hardware/software products. Look at timeframe requirements.
(What backup solutions does it recommend?)
37. Need to specify how any given file system is not POSIX-compliant so
we understand it. Make this info available to users.
(What are its POSIX shortcomings?)
More information about the gpfsug-discuss
mailing list