EncFS provides an encrypted filesystem in user-space. It runs in userspace, using the FUSE library for the filesystem interface. EncFS is open source software, licensed under the LGPL. EncFS is now over 15 years old (first release in 2003). It was written because older NFS and kernel-based encrypted filesystems such as CFS had not kept pace with Linux development. When FUSE became available, I wrote a CFS replacement for my own use and released the first version to Open Source in 2003.
https://vgough.github.io/encfs/https://github.com/vgough/encfs
An encrypted overlay filesystem written in Go. Official website: https://nuetzlich.net/gocryptfs (markdown source). gocryptfs is built on top the excellent go-fuse FUSE library. This project was inspired by EncFS and strives to fix its security issues while providing good performance (benchmarks). For details on the security of gocryptfs see the Security design document.
https://nuetzlich.net/gocryptfs/https://github.com/rfjakob/gocryptfs
FUSE (Filesystem in Userspace) is an interface for userspace programs to export a filesystem to the Linux kernel. The FUSE project consists of two components: the fuse kernel module (maintained in the regular kernel repositories) and the libfuse userspace library (maintained in this repository). libfuse provides the reference implementation for communicating with the FUSE kernel module. A FUSE file system is typically implemented as a standalone application that links with libfuse. libfuse provides functions to mount the file system, unmount it, read requests from the kernel, and send responses back. libfuse offers two APIs: a "high-level", synchronous API, and a "low-level" asynchronous API. In both cases, incoming requests from the kernel are passed to the main program using callbacks. When using the high-level API, the callbacks may work with file names and paths instead of inodes, and processing of a request finishes when the callback function returns. When using the low-level API, the callbacks must work with inodes and responses must be sent explicitly using a separate set of API functions.
https://github.com/libfuse/libfuseLXCFS is a small FUSE filesystem written with the intention of making Linux containers feel more like a virtual machine. It started as a side-project of LXC but is useable by any runtime. are container aware such that the values displayed (e.g. in /proc/uptime) really reflect how long the container is running and not how long the host is running.
https://linuxcontainers.org/lxcfshttps://github.com/lxc/lxcfs
A FUSE filesystem that provides POSIX functionality - UNIX-style permissions, ownership, special files - for filesystems that do not have such, e.g. vfat. It is a modern equivalent of the UMSDOS fs.
http://posixovl.sourceforge.nethttp://sourceforge.net/projects/posixovl
SVFS is a Virtual File System over Openstack Swift built upon fuse. It is compatible with hubiC, OVH Public Cloud Storage and basically every endpoint using a standard Openstack Swift setup. It brings a layer of abstraction over object storage, making it as accessible and convenient as a filesystem, without being intrusive on the way your data is stored. This is not an official project of the Openstack community.
https://github.com/ovh/svfsMooseFS is a Petabyte Open Source Network Distributed File System. It is easy to deploy and maintain, fault tolerant, highly performing, easily scalable, POSIX compliant. MooseFS Linux Client uses FUSE. MooseFS macOS Client uses FUSE for macOS.
https://moosefs.comhttps://github.com/moosefs/moosefs
A distributed POSIX filesystem based on TiKV, with partition tolerance and strict consistency. You can use the image on docker hub or build from the Dockerfile.
https://github.com/Hexilee/tifsSeaweedFS is a simple and highly scalable distributed file system. There are two objectives: to store billions of files! to serve the files fast! Instead of supporting full POSIX file system semantics, SeaweedFS choose to implement only a key~file mapping. Similar to the word "NoSQL", you can call it as "NoFS".
Instead of managing all file metadata in a central master, the central master only manages file volumes, and it lets these volume servers manage files and their metadata. This relieves concurrency pressure from the central master and spreads file metadata into volume servers, allowing faster file access (just one disk read operation).
SeaweedFS started by implementing Facebook's Haystack design paper. SeaweedFS is currently growing, with more features on the way.
https://groups.google.com/forum/#!forum/seaweedfs
LizardFS Software Defined Storage is a distributed, parallel, scalable, fault-tolerant, Geo-Redundant and highly available file system. It spreads data over a number of physical servers, making it visible to an end user as a single file system.
Data is distributed among multiple chunk servers. You can easily add and remove drives or the whole storage nodes. It is as simple as “plug and scale”. You can easily scale your LizardFS cluster up and down both vertically and horizontally by a single drive or a single node. You can have thousands of chunkservers and up to 1 Exabyte of data. Geo replication allows you to create geo stretched clusters stretching virtually any distance.
https://github.com/lizardfs/lizardfs
OrangeFS is a scale-out network file system designed for use on high-end computing (HEC) systems that provides very high-performance access to multi-server-based disk storage, in parallel. The OrangeFS server and client are user-level code, making them very easy to install and manage. OrangeFS has optimized MPI-IO support for parallel and distributed applications, and it is leveraged in production installations and used as a research platform for distributed and parallel storage.
http://www.orangefs.org/Gluster is a software defined distributed storage that can scale to several petabytes. It provides interfaces for object, block and file storage. It is a distributed scale-out filesystem that allows rapid provisioning of additional storage based on your storage consumption needs. It incorporates automatic failover as a primary feature.
Gluster runs on top of most unix filesystems, with XFS and ext4 being the most popular choices. Data can be accessed from just about anywhere – You can use traditional NFS, SMB/CIFS for Windows clients, or our own native GlusterFS (a few additional packages are needed on the client machines for this, but as you will see, they are quite small).
https://github.com/gluster/glusterfs
No comments:
Post a Comment