Kernel space: a better btrfs
,----[ Quote ]
| A powerful new filesystem for Linux already supports fast snapshots,
| checksums for all data, and online resizing--and plans to add ZFS-style
| built-in striping and mirroring.
`----
http://www.linuxworld.com/news/2008/012208-kernel.html?fsrc=rss-linux-news
ext4 2.6.25 Merge Plans
,----[ Quote ]
| "The following patches have been in the -mm tree for a while, and I plan to
| push them to Linus when the 2.6.25 merge window opens," began Theodore Ts'o,
| offering the patches for review before they are merged.
`----
http://kerneltrap.org/Linux/Ext4_2.6.25_Merge_Plans
Related:
Btrfs Online Resizing, Ext3 Conversion, and More
,----[ Quote ]
| Chris Mason announced version 0.10 of his new Btrfs filesystem, listing the
| following new features, "explicit back references, online resizing (including
| shrinking), in place conversion from Ext3 to Btrfs, data=ordered support,
| mount options to disable data COW and checksumming, and barrier support for
| sata and IDE drives".
`----
http://kerneltrap.org/Linux/Btrfs_Online_Resizing_Ext3_Conversion_and_More
Linux: Btrfs, File Data and Metadata Checksums
,----[ Quote ]
| Chris Mason announced an early alpha release of his new Btrfs
| filesystem, "after the last FS summit, I started working on a new
| filesystem that maintains checksums of all file data and metadata." He
| listed the following features as "mostly implemented": "extent based file
| storage (2^64 max file size), space efficient packing of small files,
| space efficient indexed directories, dynamic inode allocation, writable
| snapshots, subvolumes (separate internal filesystem roots), checksums on
| data and metadata (multiple algorithms available), very fast offline
| filesystem check".
`----
http://kerneltrap.org/node/8376
ZFS, XFS, EXT4 Filesystems Compared
,----[ Quote ]
| EXT4 is fast for metadata operations, tar, untar, cpio, and postmark. EXT4 is
| much faster than the others under FFSB. EXT4 with hardware RAID and external
| journal device is ludicrously fast. EXT4 seems to have a bad interaction with
| software RAID, probably because mkfs fails to query the RAID layout when
| setting the filesystem parameters.
|
| ZFS has excellent performance on metadata tests. ZFS has very bad sequential
| transfer with hardware RAID and appalling sequential transfer with software
| RAID. ZFS can copy the linux kernel source code in only 3 seconds! ZFS has
| equal latency for read and write requests under mixed loads, which is good.
|
| XFS has good sequential transfer under Bonnie++. Oddly XFS has better
| sequential reads when using an external journal, which makes little sense. Is
| noatime broken on XFS? XFS is very slow on all the metadata tests. XFS takes
| the RAID layout into consideration and it performs well on randomio with
| hardware or software RAID.
`----
http://tastic.brillig.org/%7Ejwb/zfs-xfs-ext4.html
Kernel and filesystem talks at OLS day two
,----[ Quote ]
| Mathur asked why not XFS or an entirely new filesystem? Largely, she
| explained, because of the large existing Ext3 community. They would be able
| to maintain backward compatibility and upgrade from Ext3 to Ext4 without the
| lengthly backup/restore process generally required to change filesystems. The
| XFS codebase, she says, is larger than Ext3's. A smaller codebase would be
| better.
`----
http://www.linux.com/feature/115767
First benchmarks of the ext4 file system
,----[ Quote ]
| The ext4 file system promises improved data integrity
| and performance, together with less limitations, and is
| definitely the step in the right way. Even if there are
| some regressions in our measurements, when compared to
| ext3, they're quite small and no doubt will be fixed
| before the development is finished. On the other hand,
| under some workloads ext4 is already showing much better
| results.
`----
http://linux.inet.hr/first_benchmarks_of_the_ext4_file_system.html
|
|
