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

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 SUSE -- 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 SUSE -- 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 [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 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 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 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 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

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

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 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 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/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 пишет:

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

On Sat, Sep 28, 2013 at 7:46 AM, Stephan Kulow wrote:

Am 27.09.2013 22:59, schrieb Andrey Borzenkov:

...

В Mon, 16 Sep 2013 12:05:21 +0200 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.

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

On 9/30/13 12:16 PM, Andrey Borzenkov wrote:

В Mon, 30 Sep 2013 09:36:01 -0400 Greg Freemyer пишет:

...

On Sat, Sep 28, 2013 at 7:46 AM, Stephan Kulow wrote:

...

Am 27.09.2013 22:59, schrieb Andrey Borzenkov:

...

В Mon, 16 Sep 2013 12:05:21 +0200 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.

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