btrfs has many of the same goals... but they are goals not code
so when you might see them is indeterminate.
I believe these should not be in btrfs:
Stephan von Krawczynski wrote:
- parallel mounts (very important!)
as Andi said, you want a cluster or distributed fs. There
are layered designs (CRFS or network filesystems) that can do
the job and trying to do it in btrfs causes too many problems.
- journaling
I assume you *do not* mean metadata journaling, you mean
sending all file updates to a single output stream (as in one
disk, tape, or network link). I've done that, but would not
recommend it in btrfs because it limits the total fs bandwidth
to what the single stream can support. This is normally done
today by applications like databases, not in the filesystem.
- map out dead blocks
Useless... a waste of time, code, and metadata structures.
With current device technology, any device reporting bad blocks
the device can not map out is about to die and needs replaced!
jim
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
