[opensuse-factory] Getting more btrfs testing for Beta1
Hi, The last btrfs bugs have shown that we just have too little coverage of btrfs. As using btrfs is a very prominent option - and hopefully our future default file system, we had some discussion how can we improve that in the remaining time frame. Our "solution" (noone likes it, but noone has a better idea either) is to add a popup asking to use btrfs during the installation of the Beta. I hope that this leads to more testing of btrfs in real life scenarios - the feedback from those using btrfs in Factory is good (just for reference, I use it too :) but IMO we have too few new installations using it. The popup is a crude hack and will be taken out during the Rc phase. Hopefully til then we found and fixed enough btrfs problems. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hello, On 09/16/2013 12:05 PM, Stephan Kulow wrote:
Our "solution" (noone likes it, but noone has a better idea either) is to add a popup asking to use btrfs during the installation of the Beta. I hope that this leads to more testing of btrfs in real life scenarios - the feedback from those using btrfs in Factory is good (just for reference, I use it too :) but IMO we have too few new installations using it.
Last time I checked (long time ago in the galaxy), it could not be installed on an encrypted partition. As my testing machine is my company laptop, where encryption is a must I stayed with extX. Is it possible to encrypt btrfs partitions now? /boot can stay unencrypted... Bye, CzP -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 16.09.2013 12:16, Peter Czanik wrote:
Hello,
On 09/16/2013 12:05 PM, Stephan Kulow wrote:
Our "solution" (noone likes it, but noone has a better idea either) is to add a popup asking to use btrfs during the installation of the Beta. I hope that this leads to more testing of btrfs in real life scenarios - the feedback from those using btrfs in Factory is good (just for reference, I use it too :) but IMO we have too few new installations using it.
Last time I checked (long time ago in the galaxy), it could not be installed on an encrypted partition. As my testing machine is my company laptop, where encryption is a must I stayed with extX. Is it possible to encrypt btrfs partitions now? /boot can stay unencrypted...
I use encrypted LVM and my home volume has btrfs - and /boot is outside of LVM. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9/16/13 6:55 AM, Stephan Kulow wrote:
On 16.09.2013 12:16, Peter Czanik wrote:
Hello,
On 09/16/2013 12:05 PM, Stephan Kulow wrote:
Our "solution" (noone likes it, but noone has a better idea either) is to add a popup asking to use btrfs during the installation of the Beta. I hope that this leads to more testing of btrfs in real life scenarios - the feedback from those using btrfs in Factory is good (just for reference, I use it too :) but IMO we have too few new installations using it.
Last time I checked (long time ago in the galaxy), it could not be installed on an encrypted partition. As my testing machine is my company laptop, where encryption is a must I stayed with extX. Is it possible to encrypt btrfs partitions now? /boot can stay unencrypted...
I use encrypted LVM and my home volume has btrfs - and /boot is outside of LVM.
I do as well. -Jeff -- Jeff Mahoney SUSE Labs
On 09/16/2013 12:55 PM, Stephan Kulow wrote:
Last time I checked (long time ago in the galaxy), it could not be installed on an encrypted partition. As my testing machine is my company laptop, where encryption is a must I stayed with extX. Is it possible to encrypt btrfs partitions now? /boot can stay unencrypted...
I use encrypted LVM and my home volume has btrfs - and /boot is outside of LVM. OK, beta1 installed in vmware. Everything except /boot is on encrypted LVM and btrfs, and it seems to work fine, except that one still needs a text console to enter the password for LVM (bug #834063). My other big problem is that XFCE/lightdm can't be shut down (bug #841985). The rest I checked in beta1 seems to work fine. Bye, CzP -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 16 septembre 2013 à 12:16 +0200, Peter Czanik a écrit :
Hello,
On 09/16/2013 12:05 PM, Stephan Kulow wrote:
Our "solution" (noone likes it, but noone has a better idea either) is to add a popup asking to use btrfs during the installation of the Beta. I hope that this leads to more testing of btrfs in real life scenarios - the feedback from those using btrfs in Factory is good (just for reference, I use it too :) but IMO we have too few new installations using it.
Last time I checked (long time ago in the galaxy), it could not be installed on an encrypted partition. As my testing machine is my company laptop, where encryption is a must I stayed with extX. Is it possible to encrypt btrfs partitions now? /boot can stay unencrypted...
Btrfs works fine on top of encrypted lvm (just like other filesystems). I can't say anything for / on encrypted lvm (but I think it should work). Maybe the installer needs some adaptation.. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Steohan, On Monday 16 September 2013 12:05:21 Stephan Kulow wrote:
The last btrfs bugs have shown that we just have too little coverage of btrfs. As using btrfs is a very prominent option - and hopefully our future default file system, we had some discussion how can we improve that in the remaining time frame.
What would be the benefits of having btrfs instead of ext4 ? I have been looking on the internet for comparison details and with kernel 4.11 it seems that ext4 is still the faster filesystem compared to btrfs ? So what would be the benefit for the average user ? I am not disputing the decision, but I would like to know what the benefits would be (if there are any) Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le lundi 16 septembre 2013 à 13:15 +0200, Raymond Wooninck a écrit :
Hi Steohan,
On Monday 16 September 2013 12:05:21 Stephan Kulow wrote:
The last btrfs bugs have shown that we just have too little coverage of btrfs. As using btrfs is a very prominent option - and hopefully our future default file system, we had some discussion how can we improve that in the remaining time frame.
What would be the benefits of having btrfs instead of ext4 ? I have been looking on the internet for comparison details and with kernel 4.11 it seems that ext4 is still the faster filesystem compared to btrfs ? So what would be the benefit for the average user ?
I am not disputing the decision, but I would like to know what the benefits would be (if there are any)
This has been discussed a lot already on the mailing list, one of the main benefits would be snapshot support (thanks to snapper), IMHO. -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Frederic Crozat <fcrozat@suse.com> [2013-09-16 13:21]:
Le lundi 16 septembre 2013 à 13:15 +0200, Raymond Wooninck a écrit :
Hi Steohan,
On Monday 16 September 2013 12:05:21 Stephan Kulow wrote:
The last btrfs bugs have shown that we just have too little coverage of btrfs. As using btrfs is a very prominent option - and hopefully our future default file system, we had some discussion how can we improve that in the remaining time frame.
What would be the benefits of having btrfs instead of ext4 ? I have been looking on the internet for comparison details and with kernel 4.11 it seems that ext4 is still the faster filesystem compared to btrfs ? So what would be the benefit for the average user ?
I am not disputing the decision, but I would like to know what the benefits would be (if there are any)
This has been discussed a lot already on the mailing list, one of the main benefits would be snapshot support (thanks to snapper), IMHO.
The benefits in terms of features are obvious, what I would find interesting would be a performance comparison for some common usage scenarios. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 16.09.2013 13:29, schrieb Guido Berhoerster:
* Frederic Crozat <fcrozat@suse.com> [2013-09-16 13:21]:
Le lundi 16 septembre 2013 à 13:15 +0200, Raymond Wooninck a écrit :
Hi Steohan,
On Monday 16 September 2013 12:05:21 Stephan Kulow wrote:
The last btrfs bugs have shown that we just have too little coverage of btrfs. As using btrfs is a very prominent option - and hopefully our future default file system, we had some discussion how can we improve that in the remaining time frame.
What would be the benefits of having btrfs instead of ext4 ? I have been looking on the internet for comparison details and with kernel 4.11 it seems that ext4 is still the faster filesystem compared to btrfs ? So what would be the benefit for the average user ?
I am not disputing the decision, but I would like to know what the benefits would be (if there are any)
This has been discussed a lot already on the mailing list, one of the main benefits would be snapshot support (thanks to snapper), IMHO.
The benefits in terms of features are obvious, what I would find interesting would be a performance comparison for some common usage scenarios.
I've installed 13.1 milestones using btrfs as root some weeks ago on VirtualBox. The system is slow like hell and I haven't found yet why. Could that be btrfs on virtualized environments? I've heard that it's not playing nice in those. Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9/16/13 7:31 AM, Wolfgang Rosenauer wrote:
Am 16.09.2013 13:29, schrieb Guido Berhoerster:
* Frederic Crozat <fcrozat@suse.com> [2013-09-16 13:21]:
Le lundi 16 septembre 2013 à 13:15 +0200, Raymond Wooninck a écrit :
Hi Steohan,
On Monday 16 September 2013 12:05:21 Stephan Kulow wrote:
The last btrfs bugs have shown that we just have too little coverage of btrfs. As using btrfs is a very prominent option - and hopefully our future default file system, we had some discussion how can we improve that in the remaining time frame.
What would be the benefits of having btrfs instead of ext4 ? I have been looking on the internet for comparison details and with kernel 4.11 it seems that ext4 is still the faster filesystem compared to btrfs ? So what would be the benefit for the average user ?
I am not disputing the decision, but I would like to know what the benefits would be (if there are any)
This has been discussed a lot already on the mailing list, one of the main benefits would be snapshot support (thanks to snapper), IMHO.
The benefits in terms of features are obvious, what I would find interesting would be a performance comparison for some common usage scenarios.
I've installed 13.1 milestones using btrfs as root some weeks ago on VirtualBox. The system is slow like hell and I haven't found yet why. Could that be btrfs on virtualized environments? I've heard that it's not playing nice in those.
It plays fine as a guest in virtualized environments. The "problems" usually crop up when using btrfs to host the VM images. That's due to copy-on-write occurring on every write. You can disable the copy-on-write for data on that file by using "chattr -C". It's safe and will do the right thing WRT snapshots of the file. -Jeff -- Jeff Mahoney SUSE Labs
On 16.09.2013 13:31, Wolfgang Rosenauer wrote:
I've installed 13.1 milestones using btrfs as root some weeks ago on VirtualBox. The system is slow like hell and I haven't found yet why. Could that be btrfs on virtualized environments? I've heard that it's not playing nice in those.
Please report such problems on bugzilla too. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi Listmates, Based on all the emails around btrfs I decided to try it for myself. I took a non-critical filesystem and tried to convert it from ext4 to btrfs. This fails terribly. The steps followed : 1) Unmount filesystem 2) Run fsck on it 3) run btrfs-convert /dev/.. The filesystem was indicated as clean after step 2. Running Step 3 has the following output: HQVMT4XX20:~ # btrfs-convert /dev/sda8 creating btrfs metadata. creating ext2fs image file. cleaning up system chunk. Segmentation fault dmesg reports 6687.468953] traps: btrfs-convert[6251] general protection ip:7f0afc68e779 sp:7fffb93b0278 error:0 in libc-2.18.so[7f0afc545000+1a5000] Based on the above I tried to check the filesystem with: HQVMT4XX20:~ # btrfsck /dev/sda8 Checking filesystem on /dev/sda8 UUID: 78c33893-dc21-4d91-81ce-db2d7aa286cc checking extents checking free space cache cache and super generation don't match, space cache will be invalidated checking fs roots root 256 inode 257 errors 800 found 5117008838 bytes used err is 1 total csum bytes: 63601216 total tree bytes: 156311552 total fs tree bytes: 56406016 total extent tree bytes: 10194944 btree space waste bytes: 36885620 file data blocks allocated: 132221116416 referenced 132221116416 Btrfs v0.20-rc1+20130701 But I can't mount the filesystem. Dmesg reports: 6688.477011] device fsid 78c33893-dc21-4d91-81ce-db2d7aa286cc devid 1 transid 23 /dev/sda8 [ 6689.254801] device fsid 78c33893-dc21-4d91-81ce-db2d7aa286cc devid 1 transid 23 /dev/sda8 [ 6749.299029] device fsid 78c33893-dc21-4d91-81ce-db2d7aa286cc devid 1 transid 23 /dev/sda8 [ 6749.301150] btrfs: disk space caching is enabled [ 6749.368809] btrfs: bad chunk start, em=0, wanted=33554432 [ 6749.368819] Failed to read block groups: -5 [ 6749.391860] btrfs: open_ctree failed Am I doing something wrong or is this a bug ? Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 17/09/13 16:02, Raymond Wooninck escribió:
HQVMT4XX20:~ # btrfs-convert /dev/sda8 creating btrfs metadata. creating ext2fs image file. cleaning up system chunk. Segmentation fault
dmesg reports 6687.468953] traps: btrfs-convert[6251] general protection ip:7f0afc68e779 sp:7fffb93b0278 error:0 in libc-2.18.so[7f0afc545000+1a5000]
Am I doing something wrong or is this a bug ?
clearly an ugly bug in the conversion tool. -- "Judging by their response, the meanest thing you can do to people on the Internet is to give them really good software for free". - Anil Dash -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mardi 17 septembre 2013 à 23:23 -0300, Cristian Rodríguez a écrit :
El 17/09/13 16:02, Raymond Wooninck escribió:
HQVMT4XX20:~ # btrfs-convert /dev/sda8 creating btrfs metadata. creating ext2fs image file. cleaning up system chunk. Segmentation fault
dmesg reports 6687.468953] traps: btrfs-convert[6251] general protection ip:7f0afc68e779 sp:7fffb93b0278 error:0 in libc-2.18.so[7f0afc545000+1a5000]
Am I doing something wrong or is this a bug ?
clearly an ugly bug in the conversion tool.
Which has been fixed on Friday evening, in filesystems:btrfsprogs (I don't think it has landed on Factory yet). -- Frederic Crozat <fcrozat@suse.com> SUSE -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wednesday 18 September 2013 09:45:36 Frederic Crozat wrote:
Am I doing something wrong or is this a bug ?
clearly an ugly bug in the conversion tool.
Which has been fixed on Friday evening, in filesystems:btrfsprogs (I don't think it has landed on Factory yet).
That is good news :) I already created https://bugzilla.novell.com/show_bug.cgi?id=840911 yesterday evening to report it, but it seems the solution is already available. I am running the latest from Factory, so the fix hasn't landed yet. Given the upcoming Beta 1 and the push for btrfs, I hope that this one can still be squished in. It is rather a nasty one. I managed to change one filesystem by backup/delete/create new filesystem/restore, but I rather use the convert utility. Thanks for the update and I will check out the update. Regards Raymond -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9/17/13 3:02 PM, Raymond Wooninck wrote:
Hi Listmates,
Based on all the emails around btrfs I decided to try it for myself. I took a non-critical filesystem and tried to convert it from ext4 to btrfs. This fails terribly.
The steps followed :
1) Unmount filesystem 2) Run fsck on it 3) run btrfs-convert /dev/..
The filesystem was indicated as clean after step 2. Running Step 3 has the following output:
HQVMT4XX20:~ # btrfs-convert /dev/sda8 creating btrfs metadata. creating ext2fs image file. cleaning up system chunk. Segmentation fault
dmesg reports 6687.468953] traps: btrfs-convert[6251] general protection ip:7f0afc68e779 sp:7fffb93b0278 error:0 in libc-2.18.so[7f0afc545000+1a5000]
Based on the above I tried to check the filesystem with: HQVMT4XX20:~ # btrfsck /dev/sda8 Checking filesystem on /dev/sda8 UUID: 78c33893-dc21-4d91-81ce-db2d7aa286cc checking extents checking free space cache cache and super generation don't match, space cache will be invalidated checking fs roots root 256 inode 257 errors 800 found 5117008838 bytes used err is 1 total csum bytes: 63601216 total tree bytes: 156311552 total fs tree bytes: 56406016 total extent tree bytes: 10194944 btree space waste bytes: 36885620 file data blocks allocated: 132221116416 referenced 132221116416 Btrfs v0.20-rc1+20130701
But I can't mount the filesystem. Dmesg reports:
6688.477011] device fsid 78c33893-dc21-4d91-81ce-db2d7aa286cc devid 1 transid 23 /dev/sda8 [ 6689.254801] device fsid 78c33893-dc21-4d91-81ce-db2d7aa286cc devid 1 transid 23 /dev/sda8 [ 6749.299029] device fsid 78c33893-dc21-4d91-81ce-db2d7aa286cc devid 1 transid 23 /dev/sda8 [ 6749.301150] btrfs: disk space caching is enabled [ 6749.368809] btrfs: bad chunk start, em=0, wanted=33554432 [ 6749.368819] Failed to read block groups: -5 [ 6749.391860] btrfs: open_ctree failed
Am I doing something wrong or is this a bug ?
Both. Any fsck wouldn't be expected to reconstruct a file system that wasn't completely constructed yet. Especially in this case where the very last step of the conversion is to move the superblock into place. Before that happens, the converted file system doesn't officially exist yet. There is a bug, obviously, in that convert is segfaulting. As Frederic noted, there's an updated btrfsprogs in filesystems:btrfsprogs that should be landing in Factory soon. The issue there was a code clean up for opening and closing the tree where it didn't account for the superblock being in a nonstandard place like it is during the conversion. If you still run into an issue with the updated btrfsprogs, let me know. -Jeff -- Jeff Mahoney SUSE Labs
On 09/16/2013 12:05 PM, Stephan Kulow wrote:
Hi,
The last btrfs bugs have shown that we just have too little coverage of btrfs. As using btrfs is a very prominent option - and hopefully our future default file system, we had some discussion how can we improve that in the remaining time frame.
Our "solution" (noone likes it, but noone has a better idea either) is to add a popup asking to use btrfs during the installation of the Beta. I hope that this leads to more testing of btrfs in real life scenarios - the feedback from those using btrfs in Factory is good (just for reference, I use it too :) but IMO we have too few new installations using it.
The popup is a crude hack and will be taken out during the Rc phase. Hopefully til then we found and fixed enough btrfs problems.
first: please tell me you resolved my bug: On 09/14/2013 03:59 AM, Sebastian wrote: can't boot my btrfs raid1 anymore second: i really really really advice against using btrfs yet unless you have backups ready and know what you are doing! i've been using btrfs for over a year now on both root and home with raid1 and compression (whereas /home is on an encrypted lvm), and had several unmountable partitions. while that has improved a lot lately, its still unstable especially with power loss or system crashes. with kernel < 3.7 you would have an unmountable drive. with 3.8 onwards you might get only ro which still means you'll have to run btrfsck or even recreate the partition. both options mean you'll be greeted with "welcome to the emergency mode!" if it is in fstab. btrfsck has improved a lot, too, but still you might get an unrepairable filesystem. oh and: you'll probably want latest btrfsck from git not the suse shipped one. moreover, for anything that uses a database (better: has many writes in small portions) like sqlite, one should at least add chattr +C (=no copy on write) to the parent folder. yes, this includes all browsers, mail clients, RPM & zypper and so on. (to do that on an already installed system you'll have to create a new folder with +C, copy the old files in it and rename that folder to the actual name). put together, btrfs is nothing for newbies, no its only for someone that has backups and - if using btrfs root - a backup or live system always ready. plus if someone from suse decides to add a "allow_unsupported" switch within initrd, your system becomes unbootable for no reason whatsoever.... -- Greetings Sebastian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Sep 16, Sebastian wrote:
i've been using btrfs for over a year now on both root and home with raid1 and compression (whereas /home is on an encrypted lvm), and had several unmountable partitions.
btrfs raid functionality? Hardware raid? mdraid? Sorry, btrfs with raid1 is a little bit to vague. If you mean brtrfs raid functionality: everybody knows that this is unstable and you should not use it, that's why Jeff Mahoney proposed to enable it only with a special command line option.
moreover, for anything that uses a database (better: has many writes in small portions) like sqlite,
For every database: journaling file systems are always the performance dead for them. There are reasons why people suggest to disable journaling always, even with ext3 and ext4, if you use databases and if you want performance.
plus if someone from suse decides to add a "allow_unsupported" switch within initrd, your system becomes unbootable for no reason whatsoever....
That's sound more like you are using the unstable features even kernel developers warns for. btrfs core is stable, but there are a lot of btrfs features, which are far away from being stable. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 09/16/2013 03:48 PM, Thorsten Kukuk wrote:
On Mon, Sep 16, Sebastian wrote:
i've been using btrfs for over a year now on both root and home with raid1 and compression (whereas /home is on an encrypted lvm), and had several unmountable partitions.
btrfs raid functionality? Hardware raid? mdraid? Sorry, btrfs with raid1 is a little bit to vague. If you mean brtrfs raid functionality: everybody knows that this is unstable and you should not use it, that's why Jeff Mahoney proposed to enable it only with a special command line option.
btrfs raid0/1 is as stable as the rest of btrfs, widely used and well tested (read #btrfs on freenode). btrfs with raid5/6 is unstable and in testing.
moreover, for anything that uses a database (better: has many writes in small portions) like sqlite,
For every database: journaling file systems are always the performance dead for them. There are reasons why people suggest to disable journaling always, even with ext3 and ext4, if you use databases and if you want performance.
the reason here for btrfs is COW. with more and more and more updates it^ll become so fragmented alone reading will take ages.
plus if someone from suse decides to add a "allow_unsupported" switch within initrd, your system becomes unbootable for no reason whatsoever....
That's sound more like you are using the unstable features even kernel developers warns for.
btrfs core is stable, but there are a lot of btrfs features, which are far away from being stable.
the question why that would render MY system unbootable, whereas btrfs would mount without problem, is still unanswered. -- Greetings Sebastian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, Sep 16, Sebastian wrote:
the question why that would render MY system unbootable, whereas btrfs would mount without problem, is still unanswered.
That was answered two sentences above ... -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 09/16/2013 04:10 PM, Thorsten Kukuk wrote:
On Mon, Sep 16, Sebastian wrote:
the question why that would render MY system unbootable, whereas btrfs would mount without problem, is still unanswered.
That was answered two sentences above ...
so, you are trying to tell me, that if i use "unsupported" features ,with which the current implementation boot fine, the suse initrd has to stop booting so I: [ ] learn my lesson [ ] switch distro [ ] get tourette syndrom ? if you want to stop people from using stuff they dont understand, tell them in the gui. if they dont use gui, its very likely they know what they are doing. BUT DONT JUST BREAK WORKING SYSTEMS! -- Greetings Sebastian -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9/16/13 10:05 AM, Sebastian wrote:
On 09/16/2013 03:48 PM, Thorsten Kukuk wrote:
On Mon, Sep 16, Sebastian wrote:
i've been using btrfs for over a year now on both root and home with raid1 and compression (whereas /home is on an encrypted lvm), and had several unmountable partitions.
btrfs raid functionality? Hardware raid? mdraid? Sorry, btrfs with raid1 is a little bit to vague. If you mean brtrfs raid functionality: everybody knows that this is unstable and you should not use it, that's why Jeff Mahoney proposed to enable it only with a special command line option.
btrfs raid0/1 is as stable as the rest of btrfs, widely used and well tested (read #btrfs on freenode). btrfs with raid5/6 is unstable and in testing.
I'm not sure what response you expect here. You're claiming it's stable. I've claimed in many locations and fairly vocally that raid (of any level) and compression are not yet. If you don't want to trust my team's determination on what's mature and what's not, that's your right. But then don't go and claim the entire file system is unstable and will lose your data when it turns out we know what we're talking about. That doesn't mean we're not going to try to fix your file system, but it does mean it's outside of the case we've established as stable.
moreover, for anything that uses a database (better: has many writes in small portions) like sqlite,
For every database: journaling file systems are always the performance dead for them. There are reasons why people suggest to disable journaling always, even with ext3 and ext4, if you use databases and if you want performance.
the reason here for btrfs is COW. with more and more and more updates it^ll become so fragmented alone reading will take ages.
It's more complicated than the cases either of you are making. In the ext* case, the cost isn't the journaling directly, it's the fsync that (at least with ext3, it's better in ext4) forces a complete journal sync. The database writes themselves don't go through the journal, but because ext* has a data=ordered implementation that basically puts all writes on the ordered list, the writes have to complete before the journal sync completes. Moving to data=writeback means that the writes don't have to complete before the journal commit. This is typically safe with databases since they tend to preallocate as well as use fsync pretty regularly. The btrfs case does involve CoW but fragmentation is pretty unrelated in the write path. We still will end up creating ordered writes and waiting for them, but we'll need to wait for the allocation to complete and the accompanying metadata tree updates that happen as well. Reads may be impacted by fragmentation but btrfs also has online defrag.
plus if someone from suse decides to add a "allow_unsupported" switch within initrd, your system becomes unbootable for no reason whatsoever....
That's sound more like you are using the unstable features even kernel developers warns for.
btrfs core is stable, but there are a lot of btrfs features, which are far away from being stable.
the question why that would render MY system unbootable, whereas btrfs would mount without problem, is still unanswered.
The allow_unsupported patch hasn't been added to the openSUSE kernel yet, so that's not what's rendering your system unbootable. -Jeff -- Jeff Mahoney SUSE Labs
On 9/16/13 7:53 AM, Sebastian wrote:
On 09/16/2013 12:05 PM, Stephan Kulow wrote:
Hi,
The last btrfs bugs have shown that we just have too little coverage of btrfs. As using btrfs is a very prominent option - and hopefully our future default file system, we had some discussion how can we improve that in the remaining time frame.
Our "solution" (noone likes it, but noone has a better idea either) is to add a popup asking to use btrfs during the installation of the Beta. I hope that this leads to more testing of btrfs in real life scenarios - the feedback from those using btrfs in Factory is good (just for reference, I use it too :) but IMO we have too few new installations using it.
The popup is a crude hack and will be taken out during the Rc phase. Hopefully til then we found and fixed enough btrfs problems.
first: please tell me you resolved my bug:
On 09/14/2013 03:59 AM, Sebastian wrote: can't boot my btrfs raid1 anymore
You reported this on Friday night and I'm afraid I rather enjoy my weekends mostly away from computers. So no, it's not fixed yet.
second: i really really really advice against using btrfs yet unless you have backups ready and know what you are doing!
i've been using btrfs for over a year now on both root and home with raid1 and compression (whereas /home is on an encrypted lvm), and had several unmountable partitions. while that has improved a lot lately, its still unstable especially with power loss or system crashes. with kernel < 3.7 you would have an unmountable drive. with 3.8 onwards you might get only ro which still means you'll have to run btrfsck or even recreate the partition. both options mean you'll be greeted with "welcome to the emergency mode!" if it is in fstab.
This is pretty much the poster child for why I've been pushing the "allow_unsupported" option. We know there are features in btrfs that aren't fully mature yet and that's how we avoid situations like this. You're welcome to test it. We appreciate the bug reports and will use the reports to improve the fs -- but you're using the feature set that we have published as immature and that I've said multiple times on this list shouldn't be used yet.
btrfsck has improved a lot, too, but still you might get an unrepairable filesystem. oh and: you'll probably want latest btrfsck from git not the suse shipped one.
This part is true and we should be more aggressive about updating and releasing btrfsprogs.
moreover, for anything that uses a database (better: has many writes in small portions) like sqlite, one should at least add chattr +C (=no copy on write) to the parent folder. yes, this includes all browsers, mail clients, RPM & zypper and so on. (to do that on an already installed system you'll have to create a new folder with +C, copy the old files in it and rename that folder to the actual name).
put together, btrfs is nothing for newbies, no its only for someone that has backups and - if using btrfs root - a backup or live system always ready.
This is FUD. You are using a file system that has features enabled that we've clearly discouraged.
plus if someone from suse decides to add a "allow_unsupported" switch within initrd, your system becomes unbootable for no reason whatsoever....
I'm not sure what you're getting at here. This is an issue for the integration of that patch. -Jeff -- Jeff Mahoney SUSE Labs
Am Montag, 16. September 2013, 12:05:21 schrieb Stephan Kulow:
Hi,
The last btrfs bugs have shown that we just have too little coverage of btrfs. As using btrfs is a very prominent option - and hopefully our future default file system, we had some discussion how can we improve that in the remaining time frame.
Our "solution" (noone likes it, but noone has a better idea either) is to add a popup asking to use btrfs during the installation of the Beta. I hope that this leads to more testing of btrfs in real life scenarios - the feedback from those using btrfs in Factory is good (just for reference, I use it too :) but IMO we have too few new installations using it.
First thing to get more testing for btrfs would be to fix BNC 834173. When trying openSUSE-Factory-NET-x86_64-Build0718 today I was hit by that bug again. It was closed a month ago and SR 186577 was opened to propagate the fix. But this SR was revoked a few days ago and I fear that there will be no fix for that in Beta1. I reopened BNC 834173 for now. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 17.09.2013 21:27, schrieb Markus Koßmann:
Am Montag, 16. September 2013, 12:05:21 schrieb Stephan Kulow:
Hi,
The last btrfs bugs have shown that we just have too little coverage of btrfs. As using btrfs is a very prominent option - and hopefully our future default file system, we had some discussion how can we improve that in the remaining time frame.
Our "solution" (noone likes it, but noone has a better idea either) is to add a popup asking to use btrfs during the installation of the Beta. I hope that this leads to more testing of btrfs in real life scenarios - the feedback from those using btrfs in Factory is good (just for reference, I use it too :) but IMO we have too few new installations using it.
First thing to get more testing for btrfs would be to fix BNC 834173. When trying openSUSE-Factory-NET-x86_64-Build0718 today I was hit by that bug again. It was closed a month ago and SR 186577 was opened to propagate the fix. But this SR was revoked a few days ago and I fear that there will be no fix for that in Beta1. I reopened BNC 834173 for now.
Don't look at request states but at the factory package. requests come and go. I think it's a bug in bernhard's script that the next request was not put in bugzilla. Anyway, you most likely tested the M4 repos with factory NET iso - the default repos on the NET isos are factory-snapshot, which is M4 and will be B1 only later. So if you want to test factory with NET isos, use factory repos. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 17.09.2013 21:27, schrieb Markus Koßmann:
Am Montag, 16. September 2013, 12:05:21 schrieb Stephan Kulow:
Hi,
The last btrfs bugs have shown that we just have too little coverage of btrfs. As using btrfs is a very prominent option - and hopefully our future default file system, we had some discussion how can we improve that in the remaining time frame.
Our "solution" (noone likes it, but noone has a better idea either) is to add a popup asking to use btrfs during the installation of the Beta. I hope that this leads to more testing of btrfs in real life scenarios - the feedback from those using btrfs in Factory is good (just for reference, I use it too :) but IMO we have too few new installations using it.
First thing to get more testing for btrfs would be to fix BNC 834173. When trying openSUSE-Factory-NET-x86_64-Build0718 today I was hit by that bug again. It was closed a month ago and SR 186577 was opened to propagate the fix. But this SR was revoked a few days ago and I fear that there will be no fix for that in Beta1. I reopened BNC 834173 for now.
Don't look at request states but at the factory package. requests come and go. I think it's a bug in bernhard's script that the next request was not put in bugzilla.
Anyway, you most likely tested the M4 repos with factory NET iso - the default repos on the NET isos are factory-snapshot, which is M4 and will be B1 only later. So if you want to test factory with NET isos, use factory repos.
Greetings, Stephan Well, I just choosed btrfs ( as root fs) for the new installation made with Build0718. And it failed because the installation system itself still uses
Am Mittwoch, 18. September 2013, 06:38:30 schrieb Stephan Kulow: the broken mkfs.btrfs. So I have to wait to try btrfs until the NET iso is rebuild based on Beta1 repos ? Or is there another option to get a fixed installation system ? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 18.09.2013 07:04, schrieb Markus Koßmann:
Well, I just choosed btrfs ( as root fs) for the new installation made with Build0718. And it failed because the installation system itself still uses the broken mkfs.btrfs. So I have to wait to try btrfs until the NET iso is rebuild based on Beta1 repos ? Or is there another option to get a fixed installation system ?
No, you need to choose the right installation source. If you see a screen like this: http://s.kulow.org/initenv, press F4 and enter the factory repos. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9/18/13 1:35 AM, Stephan Kulow wrote:
Am 18.09.2013 07:04, schrieb Markus Koßmann:
Well, I just choosed btrfs ( as root fs) for the new installation made with Build0718. And it failed because the installation system itself still uses the broken mkfs.btrfs. So I have to wait to try btrfs until the NET iso is rebuild based on Beta1 repos ? Or is there another option to get a fixed installation system ?
No, you need to choose the right installation source. If you see a screen like this: http://s.kulow.org/initenv, press F4 and enter the factory repos.
Oh neat, I didn't know about this! -Jeff -- Jeff Mahoney SUSE Labs
В Mon, 16 Sep 2013 12:05:21 +0200 Stephan Kulow <coolo@suse.de> пишет:
Hi,
The last btrfs bugs have shown that we just have too little coverage of btrfs. As using btrfs is a very prominent option - and hopefully our future default file system, we had some discussion how can we improve that in the remaining time frame.
Our "solution" (noone likes it, but noone has a better idea either) is to add a popup asking to use btrfs during the installation of the Beta. I hope that this leads to more testing of btrfs in real life scenarios - the feedback from those using btrfs in Factory is good (just for reference, I use it too :) but IMO we have too few new installations using it.
The popup is a crude hack and will be taken out during the Rc phase. Hopefully til then we found and fixed enough btrfs problems.
There does not seem to be any way to create btrfs on RAID1 during installation. Is it supposed to work? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 27.09.2013 22:59, schrieb Andrey Borzenkov:
В Mon, 16 Sep 2013 12:05:21 +0200 Stephan Kulow <coolo@suse.de> пишет:
Hi,
The last btrfs bugs have shown that we just have too little coverage of btrfs. As using btrfs is a very prominent option - and hopefully our future default file system, we had some discussion how can we improve that in the remaining time frame.
Our "solution" (noone likes it, but noone has a better idea either) is to add a popup asking to use btrfs during the installation of the Beta. I hope that this leads to more testing of btrfs in real life scenarios - the feedback from those using btrfs in Factory is good (just for reference, I use it too :) but IMO we have too few new installations using it.
The popup is a crude hack and will be taken out during the Rc phase. Hopefully til then we found and fixed enough btrfs problems.
There does not seem to be any way to create btrfs on RAID1 during installation. Is it supposed to work?
I don't know, but I would expect that btrfs does not limit your use of RAID. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Sep 28, 2013 at 7:46 AM, Stephan Kulow <coolo@suse.de> wrote:
Am 27.09.2013 22:59, schrieb Andrey Borzenkov:
В Mon, 16 Sep 2013 12:05:21 +0200 Stephan Kulow <coolo@suse.de> пишет:
Hi,
The last btrfs bugs have shown that we just have too little coverage of btrfs. As using btrfs is a very prominent option - and hopefully our future default file system, we had some discussion how can we improve that in the remaining time frame.
Our "solution" (noone likes it, but noone has a better idea either) is to add a popup asking to use btrfs during the installation of the Beta. I hope that this leads to more testing of btrfs in real life scenarios - the feedback from those using btrfs in Factory is good (just for reference, I use it too :) but IMO we have too few new installations using it.
The popup is a crude hack and will be taken out during the Rc phase. Hopefully til then we found and fixed enough btrfs problems.
There does not seem to be any way to create btrfs on RAID1 during installation. Is it supposed to work?
I don't know, but I would expect that btrfs does not limit your use of RAID.
Greetings, Stephan
It is unclear if the question relates to layering btrfs on top of an external RAID setup (ie. hardware / mdraid / dmraid / lvm) or using it's own internal RAID setup. For btrfs's internal RAID support: yast would need to add support for it before it could be used on install. That doesn't yet exist does it? The SLES filesystem team has said all flavors of btrfs internal RAID are unstable / experimental and not part of the feature set they are supporting in SLES. It brings up the question if even 13.2 should support installation to btrfs with internal RAID1 configured. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
В Mon, 30 Sep 2013 09:36:01 -0400 Greg Freemyer <greg.freemyer@gmail.com> пишет:
On Sat, Sep 28, 2013 at 7:46 AM, Stephan Kulow <coolo@suse.de> wrote:
Am 27.09.2013 22:59, schrieb Andrey Borzenkov:
В Mon, 16 Sep 2013 12:05:21 +0200 Stephan Kulow <coolo@suse.de> пишет:
Hi,
The last btrfs bugs have shown that we just have too little coverage of btrfs. As using btrfs is a very prominent option - and hopefully our future default file system, we had some discussion how can we improve that in the remaining time frame.
Our "solution" (noone likes it, but noone has a better idea either) is to add a popup asking to use btrfs during the installation of the Beta. I hope that this leads to more testing of btrfs in real life scenarios - the feedback from those using btrfs in Factory is good (just for reference, I use it too :) but IMO we have too few new installations using it.
The popup is a crude hack and will be taken out during the Rc phase. Hopefully til then we found and fixed enough btrfs problems.
There does not seem to be any way to create btrfs on RAID1 during installation. Is it supposed to work?
I don't know, but I would expect that btrfs does not limit your use of RAID.
Greetings, Stephan
It is unclear if the question relates to layering btrfs on top of an external RAID setup (ie. hardware / mdraid / dmraid / lvm) or using it's own internal RAID setup.
Internal RAID setup. I added second mirror device after installation and it works and mkinitrd seems to be happy with it (I do not know whether this is intentional or by accident :) )
For btrfs's internal RAID support: yast would need to add support for it before it could be used on install. That doesn't yet exist does it?
That was the question.
The SLES filesystem team has said all flavors of btrfs internal RAID are unstable / experimental and not part of the feature set they are supporting in SLES. It brings up the question if even 13.2 should support installation to btrfs with internal RAID1 configured.
IIRC RAID1 was said to be OK? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 9/30/13 12:16 PM, Andrey Borzenkov wrote:
В Mon, 30 Sep 2013 09:36:01 -0400 Greg Freemyer <greg.freemyer@gmail.com> пишет:
On Sat, Sep 28, 2013 at 7:46 AM, Stephan Kulow <coolo@suse.de> wrote:
Am 27.09.2013 22:59, schrieb Andrey Borzenkov:
В Mon, 16 Sep 2013 12:05:21 +0200 Stephan Kulow <coolo@suse.de> пишет:
Hi,
The last btrfs bugs have shown that we just have too little coverage of btrfs. As using btrfs is a very prominent option - and hopefully our future default file system, we had some discussion how can we improve that in the remaining time frame.
Our "solution" (noone likes it, but noone has a better idea either) is to add a popup asking to use btrfs during the installation of the Beta. I hope that this leads to more testing of btrfs in real life scenarios - the feedback from those using btrfs in Factory is good (just for reference, I use it too :) but IMO we have too few new installations using it.
The popup is a crude hack and will be taken out during the Rc phase. Hopefully til then we found and fixed enough btrfs problems.
There does not seem to be any way to create btrfs on RAID1 during installation. Is it supposed to work?
I don't know, but I would expect that btrfs does not limit your use of RAID.
Greetings, Stephan
It is unclear if the question relates to layering btrfs on top of an external RAID setup (ie. hardware / mdraid / dmraid / lvm) or using it's own internal RAID setup.
Internal RAID setup. I added second mirror device after installation and it works and mkinitrd seems to be happy with it (I do not know whether this is intentional or by accident :) )
For btrfs's internal RAID support: yast would need to add support for it before it could be used on install. That doesn't yet exist does it?
That was the question.
The SLES filesystem team has said all flavors of btrfs internal RAID are unstable / experimental and not part of the feature set they are supporting in SLES. It brings up the question if even 13.2 should support installation to btrfs with internal RAID1 configured.
IIRC RAID1 was said to be OK?
We're pretty close to calling it safe. It's used internally for metadata replication already - I just want to do some more testing to ensure it does the right thing between devices when the power fails. -Jeff -- Jeff Mahoney SUSE Labs
participants (13)
-
Andrey Borzenkov -
Cristian Rodríguez -
Frederic Crozat -
Greg Freemyer -
Guido Berhoerster -
Jeff Mahoney -
Markus Koßmann -
Peter Czanik -
Raymond Wooninck -
Sebastian -
Stephan Kulow -
Thorsten Kukuk -
Wolfgang Rosenauer