sys-fs/btrfs-heatmap::guru
- Ebuilds: 1, Testing: 9 Description: The btrfs heatmap script creates a visualization of how a btrfs filesystem is using the underlying disk space of the block devices that are added to it.
Homepage:https://github.com/knorrie/btrfs-heatmap License: MIT
sys-fs/diskonaut::guru
- Ebuilds: 3, Testing: 0.11.0, Snapshot: 9999 Description:
Given a path on your hard-drive (which could also be the root path,
eg. /). diskonaut scans it and indexes its metadata to memory so that
you could explore its contents (even while still scanning!).
Once completed, you can navigate through subfolders, getting a visual
treemap representation of what's taking up your disk space. You can
even delete files or folders and diskonaut will track how much space
you've freed up in this session.
Homepage:https://github.com/imsnif/diskonaut License: MIT
sys-fs/dwarfs::guru
- Ebuilds: 1, Testing: 0.15.3 Description:
DwarFS is a read-only file system with a focus on achieving very high compression ratios in particular for very redundant data.
This probably doesn't sound very exciting, because if it's redundant, it should compress well. However, I found that other read-only, compressed file systems don't do a very good job at making use of this redundancy. See here for a comparison with other compressed file systems.
DwarFS also doesn't compromise on speed and for my use cases I've found it to be on par with or perform better than SquashFS. For my primary use case, DwarFS compression is an order of magnitude better than SquashFS compression, it's 4 times faster to build the file system, it's typically faster to access files on DwarFS and it uses less CPU resources.
Distinct features of DwarFS are:
* Clustering of files by similarity using a similarity hash function. This makes it easier to exploit the redundancy across file boundaries.
* Segmentation analysis across file system blocks in order to reduce the size of the uncompressed file system. This saves memory when using the compressed file system and thus potentially allows for higher cache hit rates as more data can be kept in the cache.
* Highly multi-threaded implementation. Both the file system creation tool as well as the FUSE driver are able to make good use of the many cores of your system.
* Optional experimental Lua support to provide custom filtering and ordering functionality.
Homepage:https://github.com/mhx/dwarfs License: GPL-3 MIT
sys-fs/dwarfs-bin::guru
- Ebuilds: 1, Testing: 0.15.3 Description:
DwarFS is a read-only file system with a focus on achieving very high compression ratios in particular for very redundant data.
This probably doesn't sound very exciting, because if it's redundant, it should compress well. However, I found that other read-only, compressed file systems don't do a very good job at making use of this redundancy. See here for a comparison with other compressed file systems.
DwarFS also doesn't compromise on speed and for my use cases I've found it to be on par with or perform better than SquashFS. For my primary use case, DwarFS compression is an order of magnitude better than SquashFS compression, it's 4 times faster to build the file system, it's typically faster to access files on DwarFS and it uses less CPU resources.
Distinct features of DwarFS are:
* Clustering of files by similarity using a similarity hash function. This makes it easier to exploit the redundancy across file boundaries.
* Segmentation analysis across file system blocks in order to reduce the size of the uncompressed file system. This saves memory when using the compressed file system and thus potentially allows for higher cache hit rates as more data can be kept in the cache.
* Highly multi-threaded implementation. Both the file system creation tool as well as the FUSE driver are able to make good use of the many cores of your system.
* Optional experimental Python support to provide custom filtering and ordering functionality.
Homepage:https://github.com/mhx/dwarfs License: GPL-3
sys-fs/ffmpegfs::guru
- Ebuilds: 2, Testing: 2.50 Description:
FFmpegfs is a read-only FUSE filesystem which transcodes various audio and video formats to MP4, WebM, and many more on the fly when opened and read using the FFmpeg library, thus supporting a multitude of input formats and a variety of common output formats.
This allows access to a multi-media file collection with software and/or hardware which only understands one of the supported output formats, or transcodes files through simple drag-and-drop in a file browser.
Homepage:https://nschlia.github.io/ffmpegfs/ License: GPL-3+
sys-fs/gdu::guru
- Ebuilds: 1, Testing: 5.37.0 Description:
Gdu is intended primarily for SSD disks where it can fully utilize parallel processing.
However HDDs work as well, but the performance gain is not so huge.
Homepage:https://github.com/dundee/gdu License: Apache-2.0 BSD BSD-2 MIT
sys-fs/mountpoint-s3-bin::guru
- Ebuilds: 1, Testing: 1.1.1 Description:
Mountpoint for Amazon S3 is a simple, high-throughput file client for mounting an Amazon S3 bucket as a local file system. With Mountpoint for Amazon S3, your applications can access objects stored in Amazon S3 through file operations like open and read. Mountpoint for Amazon S3 automatically translates these operations into S3 object API calls, giving your applications access to the elastic storage and throughput of Amazon S3 through a file interface.
Mountpoint for Amazon S3 is optimized for applications that need high read throughput to large objects, potentially from many clients at once, and to write new objects sequentially from a single client at a time. This means it's a great fit for applications that use a file interface to:
* read large objects from S3, potentially from many instances concurrently, without downloading them to local storage first
* access only some S3 objects out of a larger data set, but can't predict which objects in advance
* upload their output to S3 directly, or upload files from local storage with tools like cp
but probably not the right fit for applications that:
* use file operations that S3 doesn't natively support, like directory renaming or symlinks
* make edits to existing files (don't work on your Git repository or run vim in Mountpoint 😄)
Mountpoint for Amazon S3 does not implement all the features of a POSIX file system, and there are some differences that may affect compatibility with your application. See Mountpoint file system behavior for a detailed description of Mountpoint for Amazon S3's behavior and POSIX support and how they could affect your application.
Homepage:https://github.com/awslabs/mountpoint-s3 License: Apache-2.0 Apache-2.0 BSD BSD-2 ISC MIT openssl Unicode-DFS-2016 ZLIB
sys-fs/xfs_undelete::guru
- Ebuilds: 1, Testing: 15.0 Description:
It tries to recover all inodes on an XFS filesystem marked as deleted.
It's rather dumb, it just looks for the magic string IN\0\0\3\2\0\0 and
considers those as deleted inodes. Then, it tries to make sense of
the extents stored in the inode (which XFS does not delete) and collect
the data blocks of the file. That file is then stored on another
filesystem in a subdirectory, by default xfs_undeleted relative to
the current directory.
Homepage:https://github.com/ianka/xfs_undelete License: GPL-3
sys-fs/zfs-auto-utils::guru
- Ebuilds: 1, Testing: 1.0.0 Description:
ZFS Automatic Scrub/Trim for Linux.
This package is ported from debian to facilitate use on other
distributions. This package renames some properties to make them more
consistent when used with zfs-auto-snapshot.
Auto TRIM is implemented using a custom per-pool property:
com.sun:auto-trim
By default, these TRIM jobs are scheduled on the first Sunday of every
month. The completion speed depends on the disks size, disk speed and
workload pattern. Cheap QLC disks could take considerable more time than
very expensive enterprise graded NVMe disks.
When com.sun:auto-trim is not present in pool, or the property is
present but value is empty/invalid, they are treated as auto.
Auto Scrub is implemented using a custom per-pool property:
com.sun:auto-scrub
By default this have a cron job entry to scrub all pools on the second
Sunday of every month at 24 minutes past midnight.
See /etc/cron.d/zfsutils-linux and /usr/libexec/zfs/scrub for details
It is possible to disable this by setting a zfs user defined property on
the root dataset for a pool.
Homepage:https://github.com/zfsonlinux License: GPL-2+