69a586f230
tested with a DEBUG+DIAGNOSTIC+LOCKDEBUG kernel. To summerise NiLFS, i'll repeat my posting to tech-kern here: NiLFS stands for New implementation of Logging File System; LFS done right they claim :) It is at version 2 now and is being developed by NTT, the Japanese telecom company and recently put into the linux source tree. See http://www.nilfs.org. The on-disc format is not completely frozen and i expect at least one minor revision to come in time. The benefits of NiLFS are build-in fine-grained checkpointing, persistent snapshots, multiple mounts and very large file and media support. Every checkpoint can be transformed into a snapshot and v.v. It is said to perform very well on flash media since it is not overwriting pieces apart from a incidental update of the superblock, but that might change. It is accompanied by a cleaner to clean up the segments and recover lost space. My work is not a port of the linux code; its a new implementation. Porting the code would be more work since its very linux oriented and never written to be ported outside linux. The goal is to be fully interchangable. The code is non intrusive to other parts of the kernel. It is also very light-weight. The current state of the code is read-only access to both clean and dirty NiLFS partitions. On mounting a dirty partition it rolls forward the log to the last checkpoint. Full read-write support is however planned! Just as the linux code, mount_nilfs allows for the `head' to be mounted read/write and allows multiple read-only snapshots/checkpoint mounts next to it. By allowing the RW mount at a different snapshot for read-write it should be possible eventually to revert back to a previous state; i.e. try to upgrade a system and being able to revert to the exact state prior to the upgrade. Compared to other FS's its pretty light-weight, suitable for embedded use and on flash media. The read-only code is currently 17kb object code on NetBSD/i386. I doubt the read-write code will surpass the 50 or 60. Compared this to FFS being 156kb, UDF being 84 kb and NFS being 130kb. Run-time memory usage is most likely not very different from other uses though maybe a bit higher than FFS.
7 lines
185 B
Makefile
7 lines
185 B
Makefile
# $NetBSD: Makefile,v 1.18 2009/07/18 16:31:42 reinoud Exp $
|
|
|
|
SUBDIR= adosfs cd9660 efs filecorefs hfs msdosfs nilfs ntfs puffs smbfs \
|
|
sysvbfs tmpfs udf union
|
|
|
|
.include <bsd.kinc.mk>
|