3.6.3-3.fc18.x86_64.debug
btrfs-progs-0.20.rc1.20121017git91d9eec-1.fc18.x86_64
I'm getting a very different result with this kernel compared to 3.6.2, when I
do the same thing. I fill the btrfs volume to 97% full again, no errors. Add a
device of the *same* size, and then device delete.
In
On 2012-10-24 23:43, Chris Murphy wrote:
However this page
https://btrfs.wiki.kernel.org/index.php/Project_ideas#Drive_swapping
states that someone is working on this kind of issue.
Yep, I see I'm merely stating what is already known, sorry about that.
No, please; you are really
On 2012-10-24 21:13, Chris Murphy wrote:
On Oct 24, 2012, at 12:06 PM, Goffredo Baroncelli
kreij...@gmail.com wrote:
I was able to reproduce it:
- I filled the filesystem until I got No space left on device.
I didn't even need to get that far.
So it seems that I spread all the
On Oct 24, 2012, at 3:30 PM, Goffredo Baroncelli kreij...@gmail.com wrote:
On 2012-10-24 21:13, Chris Murphy wrote:
It's an interesting solution, but difficult for a larger file system.
Or at least, could be very time consuming.
It is not a solution but a workaround.
Understood.
Aside
On 22 Oct 2012 18:18 +0100, from h...@carfax.org.uk (Hugo Mills):
[root@f18v ~]# btrfs device delete /dev/sdb /mnt
[root@f18v ~]# btrfs fi show
failed to read /dev/sr0
Label: none uuid: 6e96a96e-3357-4f23-b064-0f0713366d45
Total devices 5 FS bytes used 7.52GB
devid5 size
On 2012-10-23 09:57, Michael Kjörling wrote:
On 22 Oct 2012 18:18 +0100, from h...@carfax.org.uk (Hugo Mills):
[root@f18v ~]# btrfs device delete /dev/sdb /mnt [root@f18v ~]#
btrfs fi show failed to read /dev/sr0 Label: none uuid:
6e96a96e-3357-4f23-b064-0f0713366d45 Total devices 5 FS bytes
On 2012-10-23 20:17, Chris Murphy wrote:
On Oct 23, 2012, at 12:10 PM, Goffredo Baroncelli kreij...@gmail.com wrote:
I think that what Chris [Murphy] was reported is a bug of the btrfs
user space program (which is corrected in the latest git).
Unfortunately we don't know which version Chris
On Oct 23, 2012, at 1:02 PM, Goffredo Baroncelli kreij...@inwind.it wrote:
On 2012-10-23 20:17, Chris Murphy wrote:
btrfs-progs-0.20.rc1.20121017git91d9eec-1.fc18.x86_64
Definitely this version contains my patch.
Are you able to reproduce this bug (the missing device warning)?
Yes.
Hi Chris,
I was able to reproduce (partially) your behaviour.
First I created 3 disk of 3GB. I formatted them, then I filled them with
$ dd if=/dev/zero of=/mnt/btrfs1/bigfile bs=1M count=$((7*1024))
Then I got
$ sudo /mnt/home-ghigo/btrfs/btrfs-progs/btrfs fi sh
Label: 'test1' uuid:
On Oct 23, 2012, at 4:16 PM, Goffredo Baroncelli kreij...@inwind.it wrote:
$ sudo /mnt/home-ghigo/btrfs/btrfs-progs/btrfs fi sh
Label: 'test1' uuid: 7ba72d6f-d226-4e8c-9a9c-92a7fd89cd99
Total devices 4 FS bytes used 7.01GB
devid4 size 12.00GB used 3.21GB path /dev/vdf
On Oct 21, 2012, at 10:32 PM, Chris Murphy li...@colorremedies.com wrote:
This is stock Fedora 18 beta kernel, 3.6.1-1.fc18.x86_64 #1 SMP Mon Oct 8
17:19:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Probably not a good idea to omit this is a beta *test candidate* not a beta.
Two things that
On Mon, Oct 22, 2012 at 12:02:08AM -0600, Chris Murphy wrote:
On Oct 21, 2012, at 10:32 PM, Chris Murphy li...@colorremedies.com wrote:
This is stock Fedora 18 beta kernel, 3.6.1-1.fc18.x86_64 #1 SMP Mon Oct 8
17:19:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Probably not a good idea
Thanks for the response Hugo,
On Oct 22, 2012, at 3:19 AM, Hugo Mills h...@carfax.org.uk wrote:
I'm not entirely sure what's going on here(*), but it looks like an
awkward interaction between the unequal sizes of the devices, the fact
that three of them are very small, and the
On 2012-10-22 18:42, Chris Murphy wrote:
[root@f18v ~]# btrfs fi show
failed to read /dev/sr0
Label: none uuid: 6e96a96e-3357-4f23-b064-0f0713366d45
Total devices 5 FS bytes used 7.52GB
devid5 size 12.00GB used 4.17GB path /dev/sdf
devid4 size 12.00GB used 4.62GB
On Mon, Oct 22, 2012 at 10:42:18AM -0600, Chris Murphy wrote:
Thanks for the response Hugo,
On Oct 22, 2012, at 3:19 AM, Hugo Mills h...@carfax.org.uk wrote:
I'm not entirely sure what's going on here(*), but it looks like an
awkward interaction between the unequal sizes of the
On Oct 22, 2012, at 11:04 AM, Goffredo Baroncelli kreij...@gmail.com wrote:
Which version of btrfs tool are you using ? There was a bug on this.
Try the latest.
No idea.
On Oct 22, 2012, at 11:18 AM, Hugo Mills h...@carfax.org.uk wrote:
It's more like a balance which moves everything
On Mon, Oct 22, 2012 at 01:36:31PM -0600, Chris Murphy wrote:
On Oct 22, 2012, at 11:18 AM, Hugo Mills h...@carfax.org.uk wrote:
It's more like a balance which moves everything that has some (part
of its) existence on a device. So when you have RAID-0 or RAID-1 data,
all of the related
On 2012-10-22 21:50, Hugo Mills wrote:
It's more like a balance which moves everything that has
some (part of its) existence on a device. So when you have
RAID-0 or RAID-1 data, all of the related chunks on other
disks get moved too (so in RAID-1, it's the mirror chunk as
well as the chunk on
On Oct 22, 2012, at 1:50 PM, Hugo Mills h...@carfax.org.uk wrote:
Yes, the automatic single - RAID-0 upgrade was fixed. If you
haven't run a balance on (at least) the metadata after adding the new
device, then you won't get the DUP - RAID-1 upgrade on metadata. (I
can tell you haven't run
Summary: 3 drive raid0 btrfs volume, in a VM. There is no data at risk at all.
Purely a test. The volume is pretty much full. I added a larger drive /dev/sde
to the existing btrfs volume; then tried to remove one of the smaller drives.
I'm getting an error removing the device. It seems this
On 10/22/2012 01:32 PM, Chris Murphy wrote:
Summary: 3 drive raid0 btrfs volume, in a VM. There is no data at risk at all.
Purely a test. The volume is pretty much full. I added a larger drive /dev/sde
to the existing btrfs volume; then tried to remove one of the smaller drives.
I'm getting
On Oct 21, 2012, at 11:04 PM, dima dole...@parallels.com wrote:
Might be you need to balance first after adding a new disk
btrfs filesystem balance /mnt
Good idea, although I'd argue this is potentially a huge problem if a large
file system needed to be rebalanced (could take days or weeks)
22 matches
Mail list logo
