Beyond that, the management capabilities at this point don't look
ready for long term use in a production environment. By this I
mean adding/removing disks,
That much is already there and working.
Only for the basics though, yes? Disks can be added, but IIRC you can't
really control RAID
Hello,
It's stable *for you* when it functions with the workloads *you*
expect of it, with a failure rate that is acceptable *to you*.
I think there's a few ancillary things like a working fsck needed
before it can even be recommended for widespread use, even to users
willing to risk any
On Mon, 2 Aug 2010 15:05:56 +0200, Xavier Nicollet nicol...@jeru.org
wrote:
Le 02 août 2010 à 14:40, Sami Liedes a écrit:
[BTRFS supports only 256 hard-links per directory ...] but if it
indeed needs a disk format change, I think this should be considered
before the format is set in stone. I
On Tue, 29 Jun 2010 18:34:13 +0200, Hubert Kario h...@qbs.com.pl wrote:
On Tuesday 29 June 2010 12:37:45 Daniel Kozlowski wrote:
On Mon, Jun 28, 2010 at 10:31 PM, Rodrigo E. De León Plicet
rdele...@gmail.com wrote:
On Mon, Jun 28, 2010 at 8:48 AM, Daniel Kozlowski
Hi Chris,
Cheers for the informative response. :)
In the ideal implementation, the grub.conf has a list of devices it is
allowed to scan, and we put the FS uuid directly in there, let grub scan
them and we'll be able to boot off multiple volumes in that way.
Hm... perhaps it doesn't even
Hi,
A quick googling turns up posts that GRUB support for BTRFS is planned. My
curiosity is more towards how this will be managed, because the way this is
currently implemented with software RAID/LVM is quite haphazard. I
therefore have some questions about GRUB + BTRFS:
-With GRUB booting, it's
The second is an implementation detail of the linux swap file code. It
expects filesystems don't move blocks around, and takes a mapping of the
blocks in the FS once.
This doesn't work with btrfs because we do move blocks around all the
time.
That's interesting. I have a few questions:
