[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <18031.26764.586958.632146@stoffel.org>
Date: Tue, 12 Jun 2007 23:46:20 -0400
From: "John Stoffel" <john@...ffel.org>
To: Chris Mason <chris.mason@...cle.com>
Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [ANNOUNCE] Btrfs: a copy on write, snapshotting FS
>>>>> "Chris" == Chris Mason <chris.mason@...cle.com> writes:
Chris> After the last FS summit, I started working on a new filesystem
Chris> that maintains checksums of all file data and metadata. Many
Chris> thanks to Zach Brown for his ideas, and to Dave Chinner for his
Chris> help on benchmarking analysis.
Chris> The basic list of features looks like this:
Chris> * Extent based file storage (2^64 max file size)
Chris> * Space efficient packing of small files
Chris> * Space efficient indexed directories
Chris> * Dynamic inode allocation
Chris> * Writable snapshots
Chris> * Subvolumes (separate internal filesystem roots)
Chris> - Object level mirroring and striping
Chris> * Checksums on data and metadata (multiple algorithms available)
Chris> - Strong integration with device mapper for multiple device support
Chris> - Online filesystem check
Chris> * Very fast offline filesystem check
Chris> - Efficient incremental backup and FS mirroring
So, can you resize a filesystem both bigger and smaller? Or is that
implicit in the Object level mirroring and striping?
As a user of Netapps, having quotas (if only for reporting purposes)
and some way to migrate non-used files to slower/cheaper storage would
be great.
Ie. being able to setup two pools, one being RAID6, the other being
RAID1, where all currently accessed files are in the RAID1 setup, but
if un-used get migrated to the RAID6 area.
And of course some way for efficient backups and more importantly
RESTORES of data which is segregated like this.
John
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists