HAMMER (file system): Difference between revisions
No edit summary |
|||
| Line 1: | Line 1: | ||
Bellend |
|||
{{For|the Marvel Comics organization|H.A.M.M.E.R.}} |
|||
{{Primary sources|date=November 2010}} |
|||
{{Infobox filesystem |
|||
| name = HAMMER |
|||
| developer = [[Matthew Dillon (computer scientist)|Matthew Dillon]] |
|||
| full_name = HAMMER |
|||
| introduction_date = July 21, 2008 |
|||
| introduction_os = [[DragonFly BSD]] 2.0 |
|||
| partition_id = |
|||
| directory_struct = [[B-tree]] |
|||
| file_struct = |
|||
| bad_blocks_struct = |
|||
| max_file_size = |
|||
| max_files_no = |
|||
| max_filename_size = |
|||
| max_volume_size = 1 [[EiB]] |
|||
| dates_recorded = |
|||
| date_range = |
|||
| date_resolution = |
|||
| forks_streams = |
| forks_streams = |
||
| attributes = |
| attributes = |
||
Revision as of 12:45, 14 November 2011
Bellend | forks_streams = | attributes = | file_system_permissions = | compression = | data_deduplication = Yes | encryption = | OS = DragonFly BSD }} HAMMER is a high-availability 64-bit file system developed by Matthew Dillon for DragonFly BSD using B-trees. Its major features include infinite NFS-exportable snapshots, master-multislave operation, configurable history retention, fsckless-mount, and checksums to deal with data corruption.[1] HAMMER also supports data block deduplication—identical data blocks will only be stored once on a file system.[2]
Features
- Keeps configurable fine-grained filesystem history (30-second boundaries typically).
- Keeps configurable coarse-grained filesystem history (60 days daily by default).
- History and snapshots are accessible via the live filesystem.
- Near real-time log-less streaming mirroring to slaves or backups.
- Slave can have different retention parameters.
- CRC checksumming of data and metadata.
- Minimal remount time (no fsck required).
- Designed from the ground up for large fan-out mirroring.
- Support for very large file-systems (up to 1 exabyte).
- Offline recovery after a catastrophic failure is possible.
- Ability to re-optimize the layout in the background, on a live filesystem.
- Data deduplication
- Future - multi-master clustering
- Future - data compression
Limitations
Requires a pruning/reblocking cron job run a few minutes every night to incrementally clean up and regain space on the filesystem. Deletions do not immediately reclaim space.
Does not yet support multi-master configuration.
Platforms
See also
Notes
- ^ Wildner, Sascha. "HAMMER(5)". DragonFly On-Line Manual Pages. Retrieved April 3, 2009. "After a non-graceful system shutdown, HAMMER file systems will be brought back into a fully coherent state when mounting the file system, usually within a few seconds."
- ^ http://www.shiningsilence.com/dbsdlog/2010/11/07/6740.html
References
- hammer(8) Manpage.
External links
- The HAMMER Filesystem documentation page at DragonFly BSD
- Porting the HAMMER File System to Linux
- HAMMER-related articles at KernelTrap
- Matthew Dillon (21 June 2008). "THE HAMMER FILESYSTEM" (PDF). Retrieved 2009-03-02.
- HAMMER2 PRELIMINARY DESIGN DOCUMENT Matthew Dillon's notes about the next iteration of Hammer.
 | This computer data storage-related software article is a stub. You can help Wikipedia by expanding it. |