In response to your original questions, btrfs currently gives no control over the allocation of data or metadata. I'm sure someone will implement more control eventually.
On Wed, Jul 28, 2010 at 11:49:33PM +0800, wks1986 wrote: > Another issue is the speed of fsck. There will always be times when > the operating system is brought down abnormally and fsck is necessary. > In order to make the downtime as short as possible, fsck should be > fast. In this case, when metadata are stored in a fast device, fsck > will be significantly faster. The "hot data tracking" patch is based > on the statistics of ONLINE accesses. Some data may suddenly become > hot when the filesystem goes offline for fsck. Actually, because of copy-on-write and other aspects of btrfs' design, there's no need for the typical use of fsck after a crash. Even once a proper fsck is finished, it will only be necessary when important information is corrupted. So it generally doesn't make sense to worry about fsck speed. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
