[opensuse-factory] Can we see BTRFS as the default in the next version of openSUSE 11.5-12.0
Hi all, Will we be seeing btrfs as the default file system in the next versions. Pending that it has matured enough. -- Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Roman Bysh wrote:
Hi all,
Will we be seeing btrfs as the default file system in the next versions.
Which purpose would it serve? -- Per Jessen, Zürich (12.6°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 03/13/2011 05:12 PM, Per Jessen wrote:
Roman Bysh wrote:
Hi all,
Will we be seeing btrfs as the default file system in the next versions.
Which purpose would it serve?
There's really a lot's of area where btrfs will become usefull. ( some of them are only avalaible in ZFS actually ) But there's a lot of place to get it stabilize first. and missing important tools like a fsck like :-) Actually (My last check was one month ago) if a corrupt appear, you loose :-( So I wouldn't see that as a default filesystem in openSUSE yet. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Ambassador GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sun, Mar 13, 2011 at 3:21 PM, Bruno Friedmann
On 03/13/2011 05:12 PM, Per Jessen wrote:
Roman Bysh wrote:
Hi all,
Will we be seeing btrfs as the default file system in the next versions.
Which purpose would it serve?
There's really a lot's of area where btrfs will become usefull. ( some of them are only avalaible in ZFS actually ) But there's a lot of place to get it stabilize first. and missing important tools like a fsck like :-) Actually (My last check was one month ago) if a corrupt appear, you loose :-(
So I wouldn't see that as a default filesystem in openSUSE yet.
8 months is a long time in Linux, it is probably too early to make a firm decision now. -Todd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
todd rme
There's really a lot's of area where btrfs will become usefull. ( some of them are only avalaible in ZFS actually ) But there's a lot of place to get it stabilize first. and missing important tools like a fsck like :-) Actually (My last check was one month ago) if a corrupt appear, you loose :-(
So I wouldn't see that as a default filesystem in openSUSE yet.
8 months is a long time in Linux, it is probably too early to make a firm decision now.
8 months is an extremely short time for a filesystem. UFS did start in late 1981, in early 1982 universities started to use it. In late 1982 Kirk McKusick (who claims that he is the father of UFS) joined the UFS group. UFS became useful for heavy production use as a mature filesystem between 1990 and 1992. ZFS started in 2001, so it now has the age to make it a mature filesystem. BTRFS however seems to be in it's early days. Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Bruno Friedmann wrote:
On 03/13/2011 05:12 PM, Per Jessen wrote:
Roman Bysh wrote:
Hi all,
Will we be seeing btrfs as the default file system in the next versions.
Which purpose would it serve?
There's really a lot's of area where btrfs will become usefull. ( some of them are only avalaible in ZFS actually ) But there's a lot of place to get it stabilize first. and missing important tools like a fsck like :-) Actually (My last check was one month ago) if a corrupt appear, you loose :-(
Regardless of the state of btrfs, what would be the purpose of making it default? -- Per Jessen, Zürich (9.4°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Monday 14 March 2011 06:56:09 Per Jessen wrote:
Bruno Friedmann wrote:
On 03/13/2011 05:12 PM, Per Jessen wrote:
Roman Bysh wrote:
Hi all,
Will we be seeing btrfs as the default file system in the next versions.
Which purpose would it serve?
There's really a lot's of area where btrfs will become usefull. ( some of them are only avalaible in ZFS actually ) But there's a lot of place to get it stabilize first. and missing important tools like a fsck like :-) Actually (My last check was one month ago) if a corrupt appear, you loose :-(
Regardless of the state of btrfs, what would be the purpose of making it default?
Ok lets twist that around "what is the point of making Ext4 default " AFAICS it is n o different it winds me up having to keep chaning ext4 out all the time never had one good ext* file system they have all borked totally . Pete -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.7-0.7-desktop KDE Development Platform: 4.5.5 (KDE 4.5.5) "release 1" 07:28 up 15:00, 4 users, load average: 0.08, 0.02, 0.01 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 14/03/2011 07:56, Per Jessen a écrit :
Regardless of the state of btrfs, what would be the purpose of making it default?
coping with new high capacity hardware? going where the most active developpers are? jdd -- http://www.dodin.net http://www.dailymotion.com/video/xgxog7_clip-l-ombre-et-la-lumiere-3-bad-pig... http://www.youtube.com/watch?v=FGgv_ZFtV14 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
jdd wrote:
Le 14/03/2011 07:56, Per Jessen a écrit :
Regardless of the state of btrfs, what would be the purpose of making it default?
coping with new high capacity hardware?
going where the most active developpers are?
Can both still be done without having default=btrfs. -- Per Jessen, Zürich (9.6°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/14/2011 04:23 AM, jdd wrote:
Le 14/03/2011 07:56, Per Jessen a écrit :
Regardless of the state of btrfs, what would be the purpose of making it default?
coping with new high capacity hardware?
going where the most active developpers are?
Eventually it will be the default. We already support installing onto btrfs with a /boot partition. Until the issues with grub are sorted out, it shouldn't be the default. Until the issues with error handling are solved, and they will be, it's just inviting bug reports that must always be closed with "yep, we know." - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk2DcYEACgkQLPWxlyuTD7Lo5gCeN7nmS2tVM0EFhnQ7gyUY3pu3 +ScAmwR/dKkUoaWCTamfHdOUx/8Ga4Qy =1M5H -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 03/18/2011 10:51 AM, Jeff Mahoney wrote:
On 03/14/2011 04:23 AM, jdd wrote:
Le 14/03/2011 07:56, Per Jessen a écrit :
Regardless of the state of btrfs, what would be the purpose of making it default?
coping with new high capacity hardware?
going where the most active developpers are?
Eventually it will be the default. We already support installing onto btrfs with a /boot partition. Until the issues with grub are sorted out, it shouldn't be the default. Until the issues with error handling are solved, and they will be, it's just inviting bug reports that must always be closed with "yep, we know."
-Jeff
Once Grub is resolved. Will a /boot partition still be mandatory? Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/14/2011 04:23 AM, jdd wrote:
Le 14/03/2011 07:56, Per Jessen a écrit :
Regardless of the state of btrfs, what would be the purpose of making it default?
coping with new high capacity hardware?
going where the most active developpers are?
Eventually it will be the default.
Why? I'm not overly concerned with what we choose as a default filesystem, but I would like to understand how one is chosen and in particular when and why we would choose to change (from the previous default). -- Per Jessen, Zürich (7.2°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi, On Fri, 18 Mar 2011, Per Jessen wrote:
Jeff Mahoney wrote:
On 03/14/2011 04:23 AM, jdd wrote:
Le 14/03/2011 07:56, Per Jessen a écrit :
Regardless of the state of btrfs, what would be the purpose of making it default?
coping with new high capacity hardware?
going where the most active developpers are?
Eventually it will be the default.
Why?
I'm not overly concerned with what we choose as a default filesystem, but I would like to understand how one is chosen and in particular when and why we would choose to change (from the previous default).
Reiserfs got pushed as default by SUSE to enforce development. ;-)) Viele Gruesse Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org) -- Eberhard Moenkeberg Arbeitsgruppe IT-Infrastruktur E-Mail: emoenke@gwdg.de Tel.: +49 (0)551 201-1551 ------------------------------------------------------------------------- Gesellschaft fuer wissenschaftliche Datenverarbeitung mbH Goettingen (GWDG) Am Fassberg 11, 37077 Goettingen URL: http://www.gwdg.de E-Mail: gwdg@gwdg.de Tel.: +49 (0)551 201-1510 Fax: +49 (0)551 201-2150 Geschaeftsfuehrer: Prof. Dr. Oswald Haan und Dr. Paul Suren Aufsichtsratsvorsitzender: Prof. Dr. Christian Griesinger Sitz der Gesellschaft: Goettingen Registergericht: Goettingen Handelsregister-Nr. B 598 -------------------------------------------------------------------------
On Friday March 18 2011 21:10:27 Per Jessen wrote:
Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/14/2011 04:23 AM, jdd wrote:
Le 14/03/2011 07:56, Per Jessen a écrit :
Regardless of the state of btrfs, what would be the purpose of making it default?
coping with new high capacity hardware?
going where the most active developpers are?
Eventually it will be the default.
Why?
I'm not overly concerned with what we choose as a default filesystem, but I would like to understand how one is chosen and in particular when and why we would choose to change (from the previous default).
E.g. cause you then will be able to do an automated snapshot before any zypper up or dup so you can safely roll back if anything goes wrong and quite some more. So, since even the Ext X main developer says that btrfs is the future, can you please read up on the advantages and disadvantages and until you find any serious flaws you brought up to the devs attentions just believe them since they know what they are talking about instead of yet another endless "discussion". Thanks, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Stephan Kleine wrote:
On Friday March 18 2011 21:10:27 Per Jessen wrote:
Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/14/2011 04:23 AM, jdd wrote:
Le 14/03/2011 07:56, Per Jessen a écrit :
Regardless of the state of btrfs, what would be the purpose of making it default?
coping with new high capacity hardware?
going where the most active developpers are?
Eventually it will be the default.
Why?
I'm not overly concerned with what we choose as a default filesystem, but I would like to understand how one is chosen and in particular when and why we would choose to change (from the previous default).
E.g. cause you then will be able to do an automated snapshot before any zypper up or dup so you can safely roll back if anything goes wrong and quite some more.
Perhaps a reason for using it, but not a reason for making it default.
So, since even the Ext X main developer says that btrfs is the future, can you please read up on the advantages and disadvantages and until you find any serious flaws you brought up to the devs attentions just believe them since they know what they are talking about instead of yet another endless "discussion".
I only asked a question, which you didn't answer. Note - I'm specifically NOT interested in discussing the dis/advantages of btrfs, I'm only interested in the reasoning behind making (or not) it the default for openSUSE. (is my English really that difficult to read?) -- Per Jessen, Zürich (5.7°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 19/03/2011 11:43, Per Jessen a écrit :
I only asked a question, which you didn't answer.
what kind of answer do you need? Administrative ones? who take the actual decision? I don't know, but would like to jdd -- http://www.dodin.net http://pizzanetti.fr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
what kind of answer do you need? Administrative ones? who take the actual decision?
I don't know, but would like to I think he wants an answer that just say, btrfs has this and this and
Am 19.03.2011 13:29, schrieb jdd: they and they want to have it as default too. thanks -- Kim Leyendecker (kimleyendecker@hotmail.de) openSUSE Ambassador http://www.suseusers.de.vu powered by openSUSE 11.4 | KDE 4.6 | x86_64 Notebook | usecase: Workstation openSUSE/Slashdot Profilname: openLHAG (OpenLHAG) Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute , or create your own linux distro. Give SUSE Studio a try. www.susestudio.com. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Kim Leyendecker wrote:
what kind of answer do you need? Administrative ones? who take the actual decision?
I don't know, but would like to I think he wants an answer that just say, btrfs has this and this and
Am 19.03.2011 13:29, schrieb jdd: they and they want to have it as default too.
I think you guys are missing the point completely. Try to think of the large majority of openSUSE users and then answer the question: "What are the reasons for changing the openSUSE default filesystem to btfrs?" Answers using this template please: "We should make btrfs the default filesystem in openSUSE because the vast majority [= at least 80%] of openSUSE users will significantly benefit from the following new features or qualities: [please list at least two]. Please bear in mind that the latter MUST be 1) not offered by the current default filesystem and 2) distinctly beneficial to the end-user. -- Per Jessen, Zürich (4.0°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Saturday 19 March 2011 18:48:34 Per Jessen wrote:
Kim Leyendecker wrote:
Am 19.03.2011 13:29, schrieb jdd:
what kind of answer do you need? Administrative ones? who take the actual decision?
I don't know, but would like to
I think he wants an answer that just say, btrfs has this and this and they and they want to have it as default too.
I think you guys are missing the point completely. Try to think of the large majority of openSUSE users and then answer the question:
"What are the reasons for changing the openSUSE default filesystem to btfrs?"
Answers using this template please:
"We should make btrfs the default filesystem in openSUSE because the vast majority [= at least 80%] of openSUSE users will significantly benefit from the following new features or qualities:
[please list at least two]. 1 it aint an Ext* file system always had problems with them 2 it's a lot newer so it's got to bet better 3 i hate Ext file systems
the down side is at the moment you need a small boot partition so for now i will stick with Xfs thruout
Please bear in mind that the latter MUST be 1) not offered by the current default filesystem and 2) distinctly beneficial to the end-user.
Ho ho ho thats treading a bit dangerous there Per Pete . -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.7-0.7-desktop KDE Development Platform: 4.5.5 (KDE 4.5.5) "release 1" 19:04 up 1 day 1:41, 4 users, load average: 0.55, 0.31, 0.27 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Peter Nikolic wrote:
Answers using this template please:
"We should make btrfs the default filesystem in openSUSE because the vast majority [= at least 80%] of openSUSE users will significantly benefit from the following new features or qualities:
[please list at least two].
1 it aint an Ext* file system always had problems with them 2 it's a lot newer so it's got to bet better 3 i hate Ext file systems
Pete, those are not bad at all. Not at all.
Please bear in mind that the latter MUST be 1) not offered by the current default filesystem and 2) distinctly beneficial to the end-user.
Ho ho ho thats treading a bit dangerous there Per
Just asking straight questions. -- Per Jessen, Zürich (3.5°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Saturday 19 March 2011 20:08:27 Peter Nikolic wrote:
1 it aint an Ext* file system always had problems with them 2 it's a lot newer so it's got to bet better
I hope you are joking about that. A file system always takes years to mature to the point where it is reliable enough for serious data. btrfs doesn't even have its basic feature set ready yet, never mind having it tested. Get back to me in 2015, then we can talk about using btrfs for serious things When reiserfs was new, it crashed, I lost data. When xfs (for linux) was new, it crashed, I lost data. reiserfs and (especially) xfs today are stable and reasonably reliable. It will take a while for btrfs to reach that point, no matter how much we trust the developers of it Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Saturday 19 March 2011 21:19:35 Anders Johansson wrote:
On Saturday 19 March 2011 20:08:27 Peter Nikolic wrote:
1 it aint an Ext* file system always had problems with them 2 it's a lot newer so it's got to bet better
I hope you are joking about that. A file system always takes years to mature to the point where it is reliable enough for serious data. btrfs doesn't even have its basic feature set ready yet, never mind having it tested. If i was joking it would be full of smiley's
Get back to me in 2015, then we can talk about using btrfs for serious things
When reiserfs was new, it crashed, I lost data. When xfs (for linux) was new, it crashed, I lost data.
Not had Reisefs crash not had Xfs crash had all versions of Ext* crash and burn to many times
reiserfs and (especially) xfs today are stable and reasonably reliable. It will take a while for btrfs to reach that point, no matter how much we trust the developers of it
Anders
Well i would far rather see man power going into BTRFS than any on ext* Personally i think we can get rid of Ext* quick enough . Think i may try anh experiment when i have a spare drive ti install 11.4 on and set it up to boot on Xfs and home on Btrfs see how it goes anything but Ext* Pete . -- Powered by openSUSE 11.3 (x86_64) Kernel: 2.6.34.7-0.7-desktop KDE Development Platform: 4.5.5 (KDE 4.5.5) "release 1" 18:48 up 2 days 1:24, 4 users, load average: 0.00, 0.02, 0.00 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Another question about btrfs: Is their any possibility to change the default filesystem in SUSE Studio? I´m interested in creating a Factory-like rolling release with btrfs to test it and wanted to know, if this is possible. thanks -- Kim Leyendecker (kimleyendecker@hotmail.de) openSUSE Ambassador http://www.suseusers.de.vu powered by openSUSE 11.4 | KDE 4.6 | x86_64 Notebook | usecase: Workstation openSUSE/Slashdot Profilname: openLHAG (OpenLHAG) Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute , or create your own linux distro. Give SUSE Studio a try. www.susestudio.com. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Sonntag, 20. März 2011 schrieb Kim Leyendecker:
Another question about btrfs:
Is their any possibility to change the default filesystem in SUSE Studio? I´m interested in creating a Factory-like rolling release with btrfs to test it and wanted to know, if this is possible.
kiwi supports btrfs for its file systems, I don't know if SUSE Studio supports it though. But for testing you could export the kiwi config and change the file system manually if studio does not offer a GUI way. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am 21.03.2011 10:49, schrieb Stephan Kulow:
kiwi supports btrfs for its file systems, I don't know if SUSE Studio supports it though. But for testing you could export the kiwi config and change the file system manually if studio does not offer a GUI way.
Greetings, Stephan Okay, I will try it.
thank you -- Kim Leyendecker (kimleyendecker@hotmail.de) openSUSE Ambassador http://www.suseusers.de.vu powered by openSUSE 11.4 | KDE 4.6 | x86_64 Notebook | usecase: Workstation openSUSE/Slashdot Profilname: openLHAG (OpenLHAG) Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute , or create your own linux distro. Give SUSE Studio a try. www.susestudio.com. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Btrfs will benefit users because it has built in *elastic* volume management via subvolumes. This means that users get the flexibility of having "separate" file systems without having to pre-determine how much space to allocate to each.
Built-in snapshots that don't use a pool of storage outside the filesystem to do the copy-on-write, like LVM snapshots use, mean that "zypper dup" can be rolled back. It should be possible to make this part of the process so it's seamless to the user.
There's more, but writing an email on my mobile kinda sucks.
-Jeff
--
Jeff Mahoney
(mobile)
On Mar 19, 2011, at 2:48 PM, Per Jessen
Kim Leyendecker wrote:
what kind of answer do you need? Administrative ones? who take the actual decision?
I don't know, but would like to I think he wants an answer that just say, btrfs has this and this and
Am 19.03.2011 13:29, schrieb jdd: they and they want to have it as default too.
I think you guys are missing the point completely. Try to think of the large majority of openSUSE users and then answer the question:
"What are the reasons for changing the openSUSE default filesystem to btfrs?"
Answers using this template please:
"We should make btrfs the default filesystem in openSUSE because the vast majority [= at least 80%] of openSUSE users will significantly benefit from the following new features or qualities:
[please list at least two].
Please bear in mind that the latter MUST be 1) not offered by the current default filesystem and 2) distinctly beneficial to the end-user.
-- Per Jessen, Zürich (4.0°C)
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 03/19/2011 03:23 PM, Jeff Mahoney wrote:
Btrfs will benefit users because it has built in *elastic* volume management via subvolumes. This means that users get the flexibility of having "separate" file systems without having to pre-determine how much space to allocate to each.
Built-in snapshots that don't use a pool of storage outside the filesystem to do the copy-on-write, like LVM snapshots use, mean that "zypper dup" can be rolled back. It should be possible to make this part of the process so it's seamless to the user.
There's more, but writing an email on my mobile kinda sucks.
-Jeff
-- Jeff Mahoney (mobile)
On Mar 19, 2011, at 2:48 PM, Per Jessen
wrote: Kim Leyendecker wrote:
what kind of answer do you need? Administrative ones? who take the actual decision?
I don't know, but would like to I think he wants an answer that just say, btrfs has this and this and
Am 19.03.2011 13:29, schrieb jdd: they and they want to have it as default too.
I think you guys are missing the point completely. Try to think of the large majority of openSUSE users and then answer the question:
"What are the reasons for changing the openSUSE default filesystem to btfrs?"
Answers using this template please:
"We should make btrfs the default filesystem in openSUSE because the vast majority [= at least 80%] of openSUSE users will significantly benefit from the following new features or qualities:
[please list at least two].
Please bear in mind that the latter MUST be 1) not offered by the current default filesystem and 2) distinctly beneficial to the end-user.
-- Per Jessen, Zürich (4.0°C)
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
I really like the snapshot feature to allow the user to roll back to an earlier snapshot. Not available on ext4.
This would benefit users. -- Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am 19.03.2011 20:56, schrieb Roman Bysh:
I really like the snapshot feature to allow the user to roll back to an earlier snapshot. Not available on ext4.
This would benefit users. _This would benefit users totaly_ It happens too much to me, that I crashed my workstation-system and have to reinstall all. VirtualBox gives me something to recover some snapshots. But to work on a virtualmachine all the time isn´t the right solution, right?
This would benefit the users and I think this have to be the final point to say: Okay, let us use btrfs. How many people crashes their system and have to restart at zero? I think that these people want to have a filesystem that will help them. The only thing what is against btrfs as new default filesystem is these strange GRUB thing. But, when Fedora swaped to btrfs in F16 and Ubuntu maybe will do it so too with an upcoming release, it would be better for us to swap to btrfs. thanks -- Kim Leyendecker (kimleyendecker@hotmail.de) openSUSE Ambassador http://www.suseusers.de.vu powered by openSUSE 11.4 | KDE 4.6 | x86_64 Notebook | usecase: Workstation openSUSE/Slashdot Profilname: openLHAG (OpenLHAG) Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute , or create your own linux distro. Give SUSE Studio a try. www.susestudio.com. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Kim Leyendecker wrote:
Am 19.03.2011 20:56, schrieb Roman Bysh:
I really like the snapshot feature to allow the user to roll back to an earlier snapshot. Not available on ext4.
This would benefit users.
_This would benefit users totaly_ It happens too much to me, that I crashed my workstation-system and have to reinstall all.
Are you a typical user, Kim? I know I am not, but I'm trying to put myself in his or her situation. Does anyone with our regular set of repositories really have to do regular rollbacks?? I really hope not.
VirtualBox gives me something to recover some snapshots. But to work on a virtualmachine all the time isn´t the right solution, right?
Right.
This would benefit the users and I think this have to be the final point to say: Okay, let us use btrfs. How many people crashes their system and have to restart at zero? I think that these people want to have a filesystem that will help them.
Only if they have our facilities/framework to help them too. See, that could become a genuine argument for defaulting to btrfs - "the openSUSE distro offers immediate, at the-press-of-a-button, rollback of <something or other system change>" - but only if the user install on btrfs. -- Per Jessen, Zürich (3.4°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am 19.03.2011 21:39, schrieb Per Jessen:
Are you a typical user, Kim? I know I am not, but I'm trying to put myself in his or her situation. Does anyone with our regular set of repositories really have to do regular rollbacks?? I really hope not. I think I´m a normal user.... What´s a normal user? We´ve got this disscusion times before, and I still have no clue what a normal user is.... and I´m not interested in talk about it now!
-- Kim Leyendecker (kimleyendecker@hotmail.de) openSUSE Ambassador http://www.suseusers.de.vu powered by openSUSE 11.4 | KDE 4.6 | x86_64 Notebook | usecase: Workstation openSUSE/Slashdot Profilname: openLHAG (OpenLHAG) Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute , or create your own linux distro. Give SUSE Studio a try. www.susestudio.com. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Saturday, March 19, 2011 03:39:43 PM Per Jessen wrote:
Only if they have our facilities/framework to help them too. See, that could become a genuine argument for defaulting to btrfs - "the openSUSE distro offers immediate, at the-press-of-a-button, rollback of <something or other system change>" - but only if the user install on btrfs.
This would be selling point. No one is forced to use it, but many will try it to get benefits, even with risk to reinstall system, or with drawback to run backups more often. Reasonable setup that will provide easy to install and configure backup solution, to prevent heavy data loss, plus benefits of btrfs can bring a lot of people to test it. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Roman Bysh wrote:
I really like the snapshot feature to allow the user to roll back to an earlier snapshot. Not available on ext4. This would benefit users.
This sounds(!) like a genuine feature, I admit. Not quite enough to to make btrfs the default, but important. Does it work? -- Per Jessen, Zürich (3.4°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am 19.03.2011 21:30, schrieb Per Jessen:
Not quite enough to to make btrfs the default, but important. of course it´s quite enough. Do you know how many installations are died because I haven´t known or had this feature?
thanks -- Kim Leyendecker (kimleyendecker@hotmail.de) openSUSE Ambassador http://www.suseusers.de.vu powered by openSUSE 11.4 | KDE 4.6 | x86_64 Notebook | usecase: Workstation openSUSE/Slashdot Profilname: openLHAG (OpenLHAG) Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute , or create your own linux distro. Give SUSE Studio a try. www.susestudio.com. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Kim Leyendecker wrote:
Am 19.03.2011 21:30, schrieb Per Jessen:
Not quite enough to to make btrfs the default, but important.
of course it´s quite enough. Do you know how many installations are died because I haven´t known or had this feature?
No, I don't know, but please tell me. -- Per Jessen, Zürich (3.6°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am 19.03.2011 21:41, schrieb Per Jessen:
No, I don't know, but please tell me. I don´t have count but 5-10 installations.....
-- Kim Leyendecker (kimleyendecker@hotmail.de) openSUSE Ambassador http://www.suseusers.de.vu powered by openSUSE 11.4 | KDE 4.6 | x86_64 Notebook | usecase: Workstation openSUSE/Slashdot Profilname: openLHAG (OpenLHAG) Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute , or create your own linux distro. Give SUSE Studio a try. www.susestudio.com. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, 19 Mar 2011 21:46:52 +0100
Kim Leyendecker
Am 19.03.2011 21:41, schrieb Per Jessen:
No, I don't know, but please tell me. I don´t have count but 5-10 installations.....
I would like to know how you manage to trash your installation so that a rollback to a previous snapshot is the only solution to recover. And how you would do the rollback on a non-virtual machine (assuming you trash it such that it does not boot anymore, how will you do the rollback). ext3/ext4 have been rock solid for me over the last years. On machines where I'm doing stuff like running the latest graphics drivers, always the latest kernels and FACTORY and stuff, and which are those crashing much more often than average. I never had a catastropic data loss with ext. And there is a working fsck. Not arguing against btrfs and snapshots at all, but if the reason is "our update process is broken in a way that we need to rollback the snapshot two times a week", then I'd vote for fixing the cause and not the symptoms. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/19/2011 05:06 PM, Stefan Seyfried wrote:
On Sat, 19 Mar 2011 21:46:52 +0100 Kim Leyendecker
wrote: Am 19.03.2011 21:41, schrieb Per Jessen:
No, I don't know, but please tell me. I don´t have count but 5-10 installations.....
I would like to know how you manage to trash your installation so that a rollback to a previous snapshot is the only solution to recover.
And how you would do the rollback on a non-virtual machine (assuming you trash it such that it does not boot anymore, how will you do the rollback).
ext3/ext4 have been rock solid for me over the last years. On machines where I'm doing stuff like running the latest graphics drivers, always the latest kernels and FACTORY and stuff, and which are those crashing much more often than average. I never had a catastropic data loss with ext.
And there is a working fsck.
Not arguing against btrfs and snapshots at all, but if the reason is "our update process is broken in a way that we need to rollback the snapshot two times a week", then I'd vote for fixing the cause and not the symptoms.
I used it only as an example. If this is a requirement in order to make the install/update system viable, then of course that's a bad situation that needs to be resolved. I, fortunately, haven't shared Kim's bad luck with the update system. Honestly, the feature that has the most interest for me is the subvolumes. The upshot is that you create one partition, create a btrfs on it, and then create subvolumes. They all use the same shared storage pool. You can add additional disks to expand it and all subvolumes have access to the new space. This means I'm not staring at the 10 GB I have free on /home while always doing rpm -e kernel-source during zypper dup's because my / is too small. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk2FHnYACgkQLPWxlyuTD7LUfQCfWiek0Dr08/DuatWtIkYq8sNC TdEAnjWdOfuG8FAX1WDrQIoi2dg4k0Zf =gvHI -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am 19.03.2011 22:21 schrieb Jeff Mahoney:
Honestly, the feature that has the most interest for me is the subvolumes. The upshot is that you create one partition, create a btrfs on it, and then create subvolumes. They all use the same shared storage pool. You can add additional disks to expand it and all subvolumes have access to the new space. This means I'm not staring at the 10 GB I have free on /home while always doing rpm -e kernel-source during zypper dup's because my / is too small.
Is there any advantage of btrfs over a bunch of ext3 filesystems on different lvm logical volumes? The lvm pv is a storage pool, and I can resize each lv (containing one ext3 each) as needed, so the problem you described does not happen for me. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/20/2011 11:25 AM, Carl-Daniel Hailfinger wrote:
Am 19.03.2011 22:21 schrieb Jeff Mahoney:
Honestly, the feature that has the most interest for me is the subvolumes. The upshot is that you create one partition, create a btrfs on it, and then create subvolumes. They all use the same shared storage pool. You can add additional disks to expand it and all subvolumes have access to the new space. This means I'm not staring at the 10 GB I have free on /home while always doing rpm -e kernel-source during zypper dup's because my / is too small.
Is there any advantage of btrfs over a bunch of ext3 filesystems on different lvm logical volumes? The lvm pv is a storage pool, and I can resize each lv (containing one ext3 each) as needed, so the problem you described does not happen for me.
The problem I described *does* happen to you. You're just so accustomed to the workaround that it doesn't seem like it's a problem anymore. That process is still using statically defined volume sizes, but you're resizing them when you need to shift space. That's not elastic. It's multiple steps that modify both file system and storage, and it's not a process I'd recommend to notice users. It's tough to not waste space when shrinking a file system unless you shrink it lower than you intend, shrink the block device, then grow it back up to the new limit. Another step. Another opportunity for user confusion. With btrfs, outside of the initial mkfs and a single command to create a subvolume, there are no additional steps. Each logical file system allocates space directly out of the same pool. df will show the same amount of free space on all subvolumes. It's easy and allows us the flexibility to have separate logical volumes without the hassle and risk of allocating the wrong amount of space or having to jump through hoops to change it later. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk2GJ4YACgkQLPWxlyuTD7Kz/gCfYTZQz25/CYlmMuQPiMFicLu1 Le8AnRHibmYLiyYIDe/nVW7VqlgMOPIs =s7/Q -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am 20.03.2011 17:12 schrieb Jeff Mahoney:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/20/2011 11:25 AM, Carl-Daniel Hailfinger wrote:
Am 19.03.2011 22:21 schrieb Jeff Mahoney:
Honestly, the feature that has the most interest for me is the subvolumes. The upshot is that you create one partition, create a btrfs on it, and then create subvolumes. They all use the same shared storage pool. You can add additional disks to expand it and all subvolumes have access to the new space. This means I'm not staring at the 10 GB I have free on /home while always doing rpm -e kernel-source during zypper dup's because my / is too small.
Is there any advantage of btrfs over a bunch of ext3 filesystems on different lvm logical volumes? The lvm pv is a storage pool, and I can resize each lv (containing one ext3 each) as needed, so the problem you described does not happen for me.
The problem I described *does* happen to you. You're just so accustomed to the workaround that it doesn't seem like it's a problem anymore. That process is still using statically defined volume sizes, but you're resizing them when you need to shift space. That's not elastic. It's multiple steps that modify both file system and storage, and it's not a process I'd recommend to notice users. It's tough to not waste space when shrinking a file system unless you shrink it lower than you intend, shrink the block device, then grow it back up to the new limit. Another step. Another opportunity for user confusion.
With btrfs, outside of the initial mkfs and a single command to create a subvolume, there are no additional steps. Each logical file system allocates space directly out of the same pool. df will show the same amount of free space on all subvolumes. It's easy and allows us the flexibility to have separate logical volumes without the hassle and risk of allocating the wrong amount of space or having to jump through hoops to change it later.
Thank you for the detailed explanation. I had assumed that btrfs subvolumes would provide fs fault isolation, but it seems I was mistaken. If you just want the elastic storage and don't need snapshots, emulating the subvolume feature on any filesystem should be as easy as mounting the filesystem to one of the desired mount moints, and then using mount --move to move upper-level directories of the filesystem to other desired mount points. My usage pattern is having a separate filesystem for / so I can reformat+reinstall the OS instead of upgrading (saves a lot of time) and elastic storage for all my data (in /home and /storage). Regards, Carl-Daniel -- http://www.hailfinger.org/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/21/2011 03:50 AM, Carl-Daniel Hailfinger wrote:
Am 20.03.2011 17:12 schrieb Jeff Mahoney:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/20/2011 11:25 AM, Carl-Daniel Hailfinger wrote:
Am 19.03.2011 22:21 schrieb Jeff Mahoney:
Honestly, the feature that has the most interest for me is the subvolumes. The upshot is that you create one partition, create a btrfs on it, and then create subvolumes. They all use the same shared storage pool. You can add additional disks to expand it and all subvolumes have access to the new space. This means I'm not staring at the 10 GB I have free on /home while always doing rpm -e kernel-source during zypper dup's because my / is too small.
Is there any advantage of btrfs over a bunch of ext3 filesystems on different lvm logical volumes? The lvm pv is a storage pool, and I can resize each lv (containing one ext3 each) as needed, so the problem you described does not happen for me.
The problem I described *does* happen to you. You're just so accustomed to the workaround that it doesn't seem like it's a problem anymore. That process is still using statically defined volume sizes, but you're resizing them when you need to shift space. That's not elastic. It's multiple steps that modify both file system and storage, and it's not a process I'd recommend to notice users. It's tough to not waste space when shrinking a file system unless you shrink it lower than you intend, shrink the block device, then grow it back up to the new limit. Another step. Another opportunity for user confusion.
With btrfs, outside of the initial mkfs and a single command to create a subvolume, there are no additional steps. Each logical file system allocates space directly out of the same pool. df will show the same amount of free space on all subvolumes. It's easy and allows us the flexibility to have separate logical volumes without the hassle and risk of allocating the wrong amount of space or having to jump through hoops to change it later.
Thank you for the detailed explanation. I had assumed that btrfs subvolumes would provide fs fault isolation, but it seems I was mistaken.
Yes. The underlying btrfs file system is a single file system. The subvolumes provide multiple 'views' into the file system, each with a separate root.
If you just want the elastic storage and don't need snapshots, emulating the subvolume feature on any filesystem should be as easy as mounting the filesystem to one of the desired mount moints, and then using mount --move to move upper-level directories of the filesystem to other desired mount points.
I think you're missing the point here. How is this easier? Both this solution and your original one are fairly esoteric.
My usage pattern is having a separate filesystem for / so I can reformat+reinstall the OS instead of upgrading (saves a lot of time) and elastic storage for all my data (in /home and /storage).
This is equivalent to removing the subvolume and recreating it. The advantages surrounding a reformat don't really exist in the same way they do on other file systems since it's a copy-on-write file system. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk2HV9UACgkQLPWxlyuTD7IB8wCZASRr60pMKBVljbQo8kvkN6TL 77QAn0AzPboiDGJEzEdyvj/+IdDEQVMg =KBl4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sun, 2011-03-20 at 16:25 +0100, Carl-Daniel Hailfinger wrote:
Am 19.03.2011 22:21 schrieb Jeff Mahoney:
Honestly, the feature that has the most interest for me is the subvolumes. The upshot is that you create one partition, create a btrfs on it, and then create subvolumes. They all use the same shared storage pool. You can add additional disks to expand it and all subvolumes have access to the new space. This means I'm not staring at the 10 GB I have free on /home while always doing rpm -e kernel-source during zypper dup's because my / is too small. Is there any advantage of btrfs over a bunch of ext3 filesystems on different lvm logical volumes?
With traditional LVM snapshots require free space in the VG; with BTRFs snapshots are created within the FS itself. Leaving a significant amount of uncommitted space in the VG is (a) not in any default installer I've seen and (b) rarely done by all but the most experienced users. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am 19.03.2011 22:06, schrieb Stefan Seyfried:
I would like to know how you manage to trash your installation so that a rollback to a previous snapshot is the only solution to recover. I´ve got my whole personal data on a external harddisk, on my workstation is "just" the operating system. So, when the system was crashed (A time, during a kernel upgrade my whole machine shuts down and I can´t start my system or something like this (don´t know really)) I installed it new. Another thing that happened was after a driver installation, I couldn´t start X. That wasn´t the problem. I wanted to connect with the internet to reinstall X. But I needed KDE for this, because I needed KWallet for the connection to the www (epic fail if you ask me, I never will use KWallet again!) But these little things happens sometimes to me and a snapshot feature like btrfs has would make it easier to me. I think some other users will give me their voice too.
thanks -- Kim Leyendecker (kimleyendecker@hotmail.de) openSUSE Ambassador http://www.suseusers.de.vu powered by openSUSE 11.4 | KDE 4.6 | x86_64 Notebook | usecase: Workstation openSUSE/Slashdot Profilname: openLHAG (OpenLHAG) Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute , or create your own linux distro. Give SUSE Studio a try. www.susestudio.com. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, 19 Mar 2011 22:23:16 +0100
Kim Leyendecker
Am 19.03.2011 22:06, schrieb Stefan Seyfried:
I would like to know how you manage to trash your installation so that a rollback to a previous snapshot is the only solution to recover. I´ve got my whole personal data on a external harddisk, on my workstation is "just" the operating system. So, when the system was crashed (A time, during a kernel upgrade my whole machine shuts down and I can´t start my system or something like this (don´t know really)) I installed it new.
And how would you resolve this with btrfs, if the box does not boot anymore after a crash during updating the kernel? You were not able to resolve the issue with ext*, you will not be able to do it with btrfs. Period. I'm not arguing that all the btrfs features are useless, and stuff like subvolumes (that Jeff mentioned) and snapshots are genuinely useful, I agree, but we need to make sure that plain default users, who are not able to use any of the benefits of btrfs anyway because there will be no nice frontends for them are not suffering from something less stable than the current default fs. Advanced users will be able to select their fs. One could even think about some dialog like the desktop selection for the filesystem, but with IMVHO ext4 should be the preselected default. For now. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, Mar 19, 2011 at 5:36 PM, Stefan Seyfried
On Sat, 19 Mar 2011 22:23:16 +0100 Kim Leyendecker
wrote: Am 19.03.2011 22:06, schrieb Stefan Seyfried:
I would like to know how you manage to trash your installation so that a rollback to a previous snapshot is the only solution to recover. I´ve got my whole personal data on a external harddisk, on my workstation is "just" the operating system. So, when the system was crashed (A time, during a kernel upgrade my whole machine shuts down and I can´t start my system or something like this (don´t know really)) I installed it new.
And how would you resolve this with btrfs, if the box does not boot anymore after a crash during updating the kernel? You were not able to resolve the issue with ext*, you will not be able to do it with btrfs. Period.
I'm not arguing that all the btrfs features are useless, and stuff like subvolumes (that Jeff mentioned) and snapshots are genuinely useful, I agree, but we need to make sure that plain default users, who are not able to use any of the benefits of btrfs anyway because there will be no nice frontends for them are not suffering from something less stable than the current default fs.
Advanced users will be able to select their fs. One could even think about some dialog like the desktop selection for the filesystem, but with IMVHO ext4 should be the preselected default. For now.
I don't think anyone is suggesting we make it a default until it is considered stable enough for ordinary users. I haven't seen anyone here propose that we should let ordinary users suffer at the expense of advanced users. -Todd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, Mar 19, 2011 at 3:56 PM, Roman Bysh
On 03/19/2011 03:23 PM, Jeff Mahoney wrote:
Btrfs will benefit users because it has built in *elastic* volume management via subvolumes. This means that users get the flexibility of having "separate" file systems without having to pre-determine how much space to allocate to each.
Built-in snapshots that don't use a pool of storage outside the filesystem to do the copy-on-write, like LVM snapshots use, mean that "zypper dup" can be rolled back. It should be possible to make this part of the process so it's seamless to the user.
There's more, but writing an email on my mobile kinda sucks.
-Jeff
-- Jeff Mahoney (mobile)
On Mar 19, 2011, at 2:48 PM, Per Jessen
wrote: Kim Leyendecker wrote:
what kind of answer do you need? Administrative ones? who take the actual decision?
I don't know, but would like to I think he wants an answer that just say, btrfs has this and this and
Am 19.03.2011 13:29, schrieb jdd: they and they want to have it as default too.
I think you guys are missing the point completely. Try to think of the large majority of openSUSE users and then answer the question:
"What are the reasons for changing the openSUSE default filesystem to btfrs?"
Answers using this template please:
"We should make btrfs the default filesystem in openSUSE because the vast majority [= at least 80%] of openSUSE users will significantly benefit from the following new features or qualities:
[please list at least two].
Please bear in mind that the latter MUST be 1) not offered by the current default filesystem and 2) distinctly beneficial to the end-user.
-- Per Jessen, Zürich (4.0°C)
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
I really like the snapshot feature to allow the user to roll back to an earlier snapshot. Not available on ext4.
This would benefit users.
-- Cheers!
Roman
There are solid ext3 patches floating around for that and reasonable proof of concept patches for ext4. If snapshots is the primary goal, I say get those ext4 patches into the opensuse factory kernel and start testing. I suspect that is more doable than resolving the btrfs (gpl2) / grub (gpl3) licensing issues. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 19/03/2011 22:42, Greg Freemyer a écrit :
I suspect that is more doable than resolving the btrfs (gpl2) / grub (gpl3) licensing issues.
if free software keep arging on such licence problem, free software will die. (and it's not your fault, nor mine) jdd -- http://www.dodin.net http://pizzanetti.fr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Saturday March 19 2011 22:42:58 Greg Freemyer wrote:
If snapshots is the primary goal, I say get those ext4 patches into the opensuse factory kernel and start testing. I suspect that is more doable than resolving the btrfs (gpl2) / grub (gpl3) licensing issues.
According to rpm -qi grub is GPLv2+ so there is no issue. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Grub 2 is GPLv3
-Jeff
--
Jeff Mahoney
(mobile)
On Mar 19, 2011, at 8:00 PM, Stephan Kleine
On Saturday March 19 2011 22:42:58 Greg Freemyer wrote:
If snapshots is the primary goal, I say get those ext4 patches into the opensuse factory kernel and start testing. I suspect that is more doable than resolving the btrfs (gpl2) / grub (gpl3) licensing issues.
According to rpm -qi grub is GPLv2+ so there is no issue. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am 20.03.2011 01:00, schrieb Stephan Kleine:
According to rpm -qi grub is GPLv2+ so there is no issue. http://en.wikipedia.org/wiki/GNU_GRUB
GRUB2 is GPLv3 -- Kim Leyendecker (kimleyendecker@hotmail.de) openSUSE Ambassador http://www.suseusers.de.vu powered by openSUSE 11.4 | KDE 4.6 | x86_64 Notebook | usecase: Workstation openSUSE/Slashdot Profilname: openLHAG (OpenLHAG) Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute , or create your own linux distro. Give SUSE Studio a try. www.susestudio.com. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Samstag, 19. März 2011 schrieb Roman Bysh:
I really like the snapshot feature to allow the user to roll back to an earlier snapshot. Not available on ext4.
This would benefit users.
Everyone who likes that feature can choose btrfs, really - we should support btrfs and we do. But before we switch for real, it should be the recommended file system of upstream linux, e.g. when ext4 sees no more real bug fixing we should switch. If the majority needed snapshots and volume groups, we should have made lvm default - and noone asked for it. So I see no reason to switch to btrfs (not for myself yet, nor for openSUSE). Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 19/03/2011 19:48, Per Jessen a écrit :
"What are the reasons for changing the openSUSE default filesystem to btfrs?"
most openSUSE users don't even know what a file system is (I don't sepak of this list members) there is one major reason to change: it's when the developpers stop maintainig a system to go to an other, like kde3 and kde4. I can't list any major reason to go from kde3 to kde4, but I had to do. same for filesystem. A buggy system with lot of programmers working to make it ork may be better than a stable one with no developpers to accomodate the new hardware. and there is no reason to this, only the thing we use is the thing that somebody else makes available jdd -- http://www.dodin.net http://pizzanetti.fr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, Mar 19, 2011 at 6:43 AM, Per Jessen
Stephan Kleine wrote:
On Friday March 18 2011 21:10:27 Per Jessen wrote:
Jeff Mahoney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/14/2011 04:23 AM, jdd wrote:
Le 14/03/2011 07:56, Per Jessen a écrit :
Regardless of the state of btrfs, what would be the purpose of making it default?
coping with new high capacity hardware?
going where the most active developpers are?
Eventually it will be the default.
Why?
I'm not overly concerned with what we choose as a default filesystem, but I would like to understand how one is chosen and in particular when and why we would choose to change (from the previous default).
E.g. cause you then will be able to do an automated snapshot before any zypper up or dup so you can safely roll back if anything goes wrong and quite some more.
Perhaps a reason for using it, but not a reason for making it default.
So, since even the Ext X main developer says that btrfs is the future, can you please read up on the advantages and disadvantages and until you find any serious flaws you brought up to the devs attentions just believe them since they know what they are talking about instead of yet another endless "discussion".
I only asked a question, which you didn't answer. Note - I'm specifically NOT interested in discussing the dis/advantages of btrfs, I'm only interested in the reasoning behind making (or not) it the default for openSUSE. (is my English really that difficult to read?)
-- Per Jessen, Zürich (5.7°C)
I would say there are two main reasons: 1. There are a bunch of features that both users and administrators will find useful (depending on the feature) 2. If we don't make it default, the majority of people who know enough to change it likely will, making it harder to offer support to users and encouraging less-advanced users to fiddle with the partitioning configuration which they really shouldn't touch. That is assuming it is in a state where the majority of people would change to it if they knew enough and knew how. I think we should wait to set it as the default until that is the case. -Todd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am 19.03.2011 16:10, schrieb todd rme:
I would say there are two main reasons:
1. There are a bunch of features that both users and administrators will find useful (depending on the feature)
2. If we don't make it default, the majority of people who know enough to change it likely will, making it harder to offer support to users and encouraging less-advanced users to fiddle with the partitioning configuration which they really shouldn't touch.
That is assuming it is in a state where the majority of people would change to it if they knew enough and knew how. I think we should wait to set it as the default until that is the case. Why don´t make it default in Factory and see how the things will happens. When the majority will use it, we make it default if not, we stay at ext4. Why not?
thanks -- Kim Leyendecker (kimleyendecker@hotmail.de) openSUSE Ambassador http://www.suseusers.de.vu powered by openSUSE 11.4 | KDE 4.6 | x86_64 Notebook | usecase: Workstation openSUSE/Slashdot Profilname: openLHAG (OpenLHAG) Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute , or create your own linux distro. Give SUSE Studio a try. www.susestudio.com. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, Mar 19, 2011 at 12:09 PM, Kim Leyendecker
Am 19.03.2011 16:10, schrieb todd rme:
I would say there are two main reasons:
1. There are a bunch of features that both users and administrators will find useful (depending on the feature)
2. If we don't make it default, the majority of people who know enough to change it likely will, making it harder to offer support to users and encouraging less-advanced users to fiddle with the partitioning configuration which they really shouldn't touch.
That is assuming it is in a state where the majority of people would change to it if they knew enough and knew how. I think we should wait to set it as the default until that is the case.
Why don´t make it default in Factory and see how the things will happens. When the majority will use it, we make it default if not, we stay at ext4. Why not?
Because there is no grub1 or grub2 support! That means for default openSUSE install its only good for data partitions. How many factory users even have a separate /home etc. directory to test btrfs with. I know I tend to test factory in a VM with only one / filesystem and the default grub1 boot loader. So I can't test btrfs that way. Greg -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am 19.03.2011 17:21, schrieb Greg Freemyer:
Because there is no grub1 or grub2 support! That means for default openSUSE install its only good for data partitions.
How many factory users even have a separate /home etc. directory to test btrfs with. I know I tend to test factory in a VM with only one / filesystem and the default grub1 boot loader. So I can't test btrfs that way.
Oh, I haven´t known this fact. So forgot the factory-idea. When their´s no grub1/2 support, how can it work with openSUSE at all? I mean, I can choose it when I install a new openSUSE-installation on my workstation. Do I use an other bootloader when I install it? confused -- Kim Leyendecker (kimleyendecker@hotmail.de) openSUSE Ambassador http://www.suseusers.de.vu powered by openSUSE 11.4 | KDE 4.6 | x86_64 Notebook | usecase: Workstation openSUSE/Slashdot Profilname: openLHAG (OpenLHAG) Have you tried SUSE Studio? Need to create a Live CD, an app you want to package and distribute , or create your own linux distro. Give SUSE Studio a try. www.susestudio.com. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 03/19/2011 12:21 PM, Greg Freemyer wrote:
On Sat, Mar 19, 2011 at 12:09 PM, Kim Leyendecker
wrote: Am 19.03.2011 16:10, schrieb todd rme:
I would say there are two main reasons:
1. There are a bunch of features that both users and administrators will find useful (depending on the feature)
2. If we don't make it default, the majority of people who know enough to change it likely will, making it harder to offer support to users and encouraging less-advanced users to fiddle with the partitioning configuration which they really shouldn't touch.
That is assuming it is in a state where the majority of people would change to it if they knew enough and knew how. I think we should wait to set it as the default until that is the case.
Why don´t make it default in Factory and see how the things will happens. When the majority will use it, we make it default if not, we stay at ext4. Why not?
Because there is no grub1 or grub2 support! That means for default openSUSE install its only good for data partitions.
How many factory users even have a separate /home etc. directory to test btrfs with. I know I tend to test factory in a VM with only one / filesystem and the default grub1 boot loader. So I can't test btrfs that way.
Greg I thought grub was patched last year. I'm running btrfs on an 11.3 desktop.
-- Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 03/19/2011 01:27 PM, Roman Bysh wrote:
On 03/19/2011 12:21 PM, Greg Freemyer wrote:
On Sat, Mar 19, 2011 at 12:09 PM, Kim Leyendecker
wrote: Am 19.03.2011 16:10, schrieb todd rme:
I would say there are two main reasons:
1. There are a bunch of features that both users and administrators will find useful (depending on the feature)
2. If we don't make it default, the majority of people who know enough to change it likely will, making it harder to offer support to users and encouraging less-advanced users to fiddle with the partitioning configuration which they really shouldn't touch.
That is assuming it is in a state where the majority of people would change to it if they knew enough and knew how. I think we should wait to set it as the default until that is the case.
Why don´t make it default in Factory and see how the things will happens. When the majority will use it, we make it default if not, we stay at ext4. Why not?
Because there is no grub1 or grub2 support! That means for default openSUSE install its only good for data partitions.
How many factory users even have a separate /home etc. directory to test btrfs with. I know I tend to test factory in a VM with only one / filesystem and the default grub1 boot loader. So I can't test btrfs that way.
Greg I thought grub was patched last year. I'm running btrfs on an 11.3 desktop.
Correction. There are a number of issues as Jeff commented that will be resolved. Hopefully, this year. There are several teams working on this from each major distro. -- Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, 19 Mar 2011 17:09:02 +0100
Kim Leyendecker
Why don´t make it default in Factory and see how the things will happens.
I'd guess that 90% of the Factory *users* (not only casual testers, but people who really use it) are never installing but always "zypper up"ing, so you won't get too much testing from that, unfortunately. -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
todd rme wrote:
On Sat, Mar 19, 2011 at 6:43 AM, Per Jessen
wrote: I only asked a question, which you didn't answer. Note - I'm specifically NOT interested in discussing the dis/advantages of btrfs, I'm only interested in the reasoning behind making (or not) it the default for openSUSE. (is my English really that difficult to read?)
I would say there are two main reasons:
1. There are a bunch of features that both users and administrators will find useful (depending on the feature)
That goes for just about any filesystems we currently support in YaST.
2. If we don't make it default, the majority of people who know enough to change it likely will, making it harder to offer support to users and encouraging less-advanced users to fiddle with the partitioning configuration which they really shouldn't touch.
That goes for every other filesystem that is not the default.
That is assuming it is in a state where the majority of people would change to it if they knew enough and knew how.
And why. Todd, thanks your attempt at arguing why we should change the default filesystem. Can someone advocating btrfs as the default filesystem in the next openSUSE please provide an argument along these lines: "We should make btrfs the default filesystem in openSUSE because the vast majority [= at least 80%] of openSUSE users will significantly benefit from the following new features or qualities: [please list at least two]. Thanks. -- Per Jessen, Zürich (4.2°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, Mar 19, 2011 at 2:36 PM, Per Jessen
todd rme wrote:
On Sat, Mar 19, 2011 at 6:43 AM, Per Jessen
wrote: I only asked a question, which you didn't answer. Note - I'm specifically NOT interested in discussing the dis/advantages of btrfs, I'm only interested in the reasoning behind making (or not) it the default for openSUSE. (is my English really that difficult to read?)
I would say there are two main reasons:
1. There are a bunch of features that both users and administrators will find useful (depending on the feature)
That goes for just about any filesystems we currently support in YaST.
Yes, but the other filesystems also lack major features (or are less stable) than ext2/3/4 (whichever was being used at the time). The whole point of btrfs is that it has all of the features of ext, or it will before we decide to use it.
2. If we don't make it default, the majority of people who know enough to change it likely will, making it harder to offer support to users and encouraging less-advanced users to fiddle with the partitioning configuration which they really shouldn't touch.
That goes for every other filesystem that is not the default.
That is mathematically impossible. There are at least 6 or 7 possible filesystems, a majority of people can't pick all of them.
Todd, thanks your attempt at arguing why we should change the default filesystem. Can someone advocating btrfs as the default filesystem in the next openSUSE please provide an argument along these lines:
"We should make btrfs the default filesystem in openSUSE because the vast majority [= at least 80%] of openSUSE users will significantly benefit from the following new features or qualities:
[please list at least two].
You just said that you didn't want to discuss the advantages of btrfs. We can't give you the information you are asking for without discussing the benefits of btrfs. It also seems pretty arbitrary to say that every feature of btrfs has to benefit at least 80% of the people, and is an impossible condition to satisfy. We would never have switched to ext4 if we used this criteria. A fair assessment would ask 1. Are there any drawbacks of using btrfs compared to ext4 that will effect a significant number of users 2. Are there any advantages of using btrfs compared to ext4 that will effect a significant number of users 3. Do the advantages outweigh the drawbacks for the majority of users? 4. Are there any major flaws in btrfs that should be deal-killers If the answer to 3 is yes and the answer to 4 is no, then I think we should use btrfs. Currently, issues like fsck and grub I would say are deal-killers. They may not be by the time of the next openSUSE release. As for features that could be useful to a significant number of people but are not present in ext4: 1. Per-directory compression 2. Per-directory encryption (not implemented yet, but planned and it may be done by the next release) 3. Data deduplication (not implemented yet, but planned and it may be done by the next release) 4. Incremental dumps 5. Combining multiple physical drives into a single directory tree without needing logical volumes Probably others I am not aware of. -Todd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
todd rme wrote:
Todd, thanks your attempt at arguing why we should change the default filesystem. Can someone advocating btrfs as the default filesystem in the next openSUSE please provide an argument along these lines:
"We should make btrfs the default filesystem in openSUSE because the vast majority [= at least 80%] of openSUSE users will significantly benefit from the following new features or qualities:
[please list at least two].
You just said that you didn't want to discuss the advantages of btrfs.
I want to know only about the advantages that are _important_ to at least a _majority_ of openSUSE users. By changing the default we are presumably hoping to make life easier for a big chunk of our target users. (end-users or admins who would immediately change to btrs instead <the current default>).
It also seems pretty arbitrary to say that every feature of btrfs has to benefit at least 80% of the people, and is an impossible condition to satisfy. We would never have switched to ext4 if we used this criteria.
I know, and we shouldn't have either. It was a purely arbitrary decision. Of course 80% is an arbitrary number, but we are talking about the default. Which (equally arbitrary) number are you expecting to satisfy by changing the default? I think the point has to be that it doesn't matter how many users we hope to satisfy by changing the default, and that we therefore have to look elsewhere for the reasoning.
A fair assessment would ask
1. Are there any drawbacks of using btrfs compared to ext4 that will effect a significant number of users 2. Are there any advantages of using btrfs compared to ext4 that will effect a significant number of users 3. Do the advantages outweigh the drawbacks for the majority of users? 4. Are there any major flaws in btrfs that should be deal-killers
If the answer to 3 is yes and the answer to 4 is no, then I think we should use btrfs.
Those are very good criteria, I agree. Thanks for elaborating. My answers (probably irrelevant though) to 1-3: 1. Probably not. 2. Probably not. 3. No. (probably).
Currently, issues like fsck and grub I would say are deal-killers. They may not be by the time of the next openSUSE release.
As for features that could be useful to a significant number of people but are not present in ext4:
1. Per-directory compression 2. Per-directory encryption (not implemented yet, but planned and it may be done by the next release) 3. Data deduplication (not implemented yet, but planned and it may be done by the next release) 4. Incremental dumps 5. Combining multiple physical drives into a single directory tree without needing logical volumes
Probably others I am not aware of.
I think perhaps we don't agree on what constitutes "a significant number of users". My impression is that the vast majority of our users are using a laptop or a desktop machine, and I really don't see any of those reasons above as a major advantage to any of those (nor to any of their sysadmins). -- Per Jessen, Zürich (3.6°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sat, Mar 19, 2011 at 4:19 PM, Per Jessen
todd rme wrote:
Todd, thanks your attempt at arguing why we should change the default filesystem. Can someone advocating btrfs as the default filesystem in the next openSUSE please provide an argument along these lines:
"We should make btrfs the default filesystem in openSUSE because the vast majority [= at least 80%] of openSUSE users will significantly benefit from the following new features or qualities:
[please list at least two].
You just said that you didn't want to discuss the advantages of btrfs.
I want to know only about the advantages that are _important_ to at least a _majority_ of openSUSE users. By changing the default we are presumably hoping to make life easier for a big chunk of our target users. (end-users or admins who would immediately change to btrs instead <the current default>).
But why does it have to matter to a majority of users? If it helps just 1% of users, but doesn't hurt anybody, why wouldn't we change? Ignoring the amount of work that it requires to change it, a decision on that would have to be decided on by the people responsible for implementing the change.
It also seems pretty arbitrary to say that every feature of btrfs has to benefit at least 80% of the people, and is an impossible condition to satisfy. We would never have switched to ext4 if we used this criteria.
I know, and we shouldn't have either. It was a purely arbitrary decision. Of course 80% is an arbitrary number, but we are talking about the default. Which (equally arbitrary) number are you expecting to satisfy by changing the default?
More than would be bothered by the change. It doesn't matter if it is a small number, the question is whether overall it would have a net benefit or a net detriment for users. If it has a net benefit, even a small one, then it is still a good idea to change.
A fair assessment would ask
1. Are there any drawbacks of using btrfs compared to ext4 that will effect a significant number of users 2. Are there any advantages of using btrfs compared to ext4 that will effect a significant number of users 3. Do the advantages outweigh the drawbacks for the majority of users? 4. Are there any major flaws in btrfs that should be deal-killers
If the answer to 3 is yes and the answer to 4 is no, then I think we should use btrfs.
Those are very good criteria, I agree. Thanks for elaborating.
My answers (probably irrelevant though) to 1-3:
1. Probably not. 2. Probably not. 3. No. (probably).
And you reasoning for these is?
Currently, issues like fsck and grub I would say are deal-killers. They may not be by the time of the next openSUSE release.
As for features that could be useful to a significant number of people but are not present in ext4:
1. Per-directory compression 2. Per-directory encryption (not implemented yet, but planned and it may be done by the next release) 3. Data deduplication (not implemented yet, but planned and it may be done by the next release) 4. Incremental dumps 5. Combining multiple physical drives into a single directory tree without needing logical volumes
Probably others I am not aware of.
I think perhaps we don't agree on what constitutes "a significant number of users". My impression is that the vast majority of our users are using a laptop or a desktop machine, and I really don't see any of those reasons above as a major advantage to any of those (nor to any of their sysadmins).
Once again, why should it have to affect "the vast majority of users". If the "vast majority" of users see no change whatsoever, but some power users get a benefit, isn't that still a overall benefit? I chose my words very carefully. When I said "significant", I avoided the word "majority" on purpose. I don't think what matters is that the majority benefit. What I think matter is that on average users are better off than before, even by a little bit. If just 1% of users get a benefit, and 0.9% see an equally large disadvantage, then it is still better to make the switch because on average it is beneficial. As for my specific examples: Compressing directories is pretty common if you want to save space. Not on Linux because it isn't available, but it is featured pretty prominently on windows systems. openSUSE already makes it easy to encrypt partitions, but encrypting individual directories would make, for instance, encrypting your home directory much easier (you would no longer need to make a fixed-size encrypted filesystem). Encryption is especially popular with laptops since they can be stolen easily. Data deduplication, if automated by a system tool, would be a great way to save space. It is as much an issue for home users as servers, perhaps more since they don't make as much of an effort to properly organize their files. Incremental dumps makes backups much more efficient and effective. Linux is already suffering from a lack of good backup solutions. And overall it will provide many of the features of LLVM directly in the filesystem. -Todd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 19/03/2011 22:31, todd rme a écrit :
But why does it have to matter to a majority of users? If it helps just 1% of users, but doesn't hurt anybody, why wouldn't we change?
because this part of the users already know how to use it, so they don't need the change. average users don't care, but a bit less average ones had a lot of work learning etx3, then 4 and wont like to have to learn again. I lived this with lpr versus cups, xorg automation, kde3 versus kde4 and it's pretty umpleasant to change something that works and you know by something that works but you don't know, because anything working is always "almost" working, so one always have to trick a setup at a moment or an other, and seeing it's no more what you know is bad.
Compressing directories is pretty common if you want to save space.
and it's in many cases plenty stupid. Only text can be compressed. The large files for now are video or photos and these are already compressed. The net compress gain on our time of cheap large hard drives is really not visible (or we have to see convincing statistics). A compressed FS may also be more difficult to recover, if ever a problem come, because one have to use compatible drivers.
Not on Linux because it isn't available, but it is featured pretty prominently on windows systems.
I used it and with reason 10 years ago. never more now.
Encryption is especially popular with laptops since they can be stolen easily.
yes, this is a good point
Incremental dumps makes backups much more efficient and effective. Linux is already suffering from a lack of good backup solutions.
what? there are so many... the problem is to setup a good policy for every people needs (each people have to use a personal policy to acheive a good result)
And overall it will provide many of the features of LLVM directly in the filesystem.
this is a good point. also the snapshot feature could be an enormous advantage if it works like VirtualBox snapshots. But is it really possible to be as flexible as that? Launching a snapshot for games and an other snapshot for work? jdd -- http://www.dodin.net http://pizzanetti.fr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sun, Mar 20, 2011 at 5:45 AM, jdd
Le 19/03/2011 22:31, todd rme a écrit :
But why does it have to matter to a majority of users? If it helps just 1% of users, but doesn't hurt anybody, why wouldn't we change?
because this part of the users already know how to use it, so they don't need the change.
average users don't care, but a bit less average ones had a lot of work learning etx3, then 4 and wont like to have to learn again.
I lived this with lpr versus cups, xorg automation, kde3 versus kde4 and it's pretty umpleasant to change something that works and you know by something that works but you don't know, because anything working is always "almost" working, so one always have to trick a setup at a moment or an other, and seeing it's no more what you know is bad.
What, exactly, is there to learn?
Compressing directories is pretty common if you want to save space.
and it's in many cases plenty stupid. Only text can be compressed. The large files for now are video or photos and these are already compressed. The net compress gain on our time of cheap large hard drives is really not visible (or we have to see convincing statistics). A compressed FS may also be more difficult to recover, if ever a problem come, because one have to use compatible drivers.
There are plenty of reasons why someone would have large amounts of text. Businesses, for instance. I have massive amounts of text because I am in scientific research. In fact the vast majority of one of my hard drives is text, tens of gigabytes of it.
Encryption is especially popular with laptops since they can be stolen easily.
yes, this is a good point
Incremental dumps makes backups much more efficient and effective. Linux is already suffering from a lack of good backup solutions.
what? there are so many... the problem is to setup a good policy for every people needs (each people have to use a personal policy to acheive a good result)
Just because there are lots of something doesn't mean any of them are particularly good. And even if they are, an improvement would still likely help a lot of people.
And overall it will provide many of the features of LLVM directly in the filesystem.
this is a good point. also the snapshot feature could be an enormous advantage if it works like VirtualBox snapshots. But is it really possible to be as flexible as that? Launching a snapshot for games and an other snapshot for work?
I don't know, but I didn't mention snapshots at all because I don't know enough about them. -Todd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Sun, 2011-03-20 at 12:40 -0400, todd rme wrote:
On Sun, Mar 20, 2011 at 5:45 AM, jdd
wrote: Le 19/03/2011 22:31, todd rme a écrit :
But why does it have to matter to a majority of users? If it helps just 1% of users, but doesn't hurt anybody, why wouldn't we change? because this part of the users already know how to use it, so they don't need the change. average users don't care, but a bit less average ones had a lot of work learning etx3, then 4 and wont like to have to learn again. I lived this with lpr versus cups, xorg automation, kde3 versus kde4 and it's pretty umpleasant to change something that works and you know by something that works but you don't know, because anything working is always "almost" working, so one always have to trick a setup at a moment or an other, and seeing it's no more what you know is bad. What, exactly, is there to learn?
[as a professional sys-admin] Or "was there to learn?". Ext2 to Ext3 was a pretty much unopposed change and a clear net win [gone were frequent and loooong running fsck checks]. The transition for Ext3 -> Ext4 was almost unnoticed except in the largest scenarios.
Compressing directories is pretty common if you want to save space. and it's in many cases plenty stupid. Only text can be compressed. The large files for now are video or photos and these are already compressed.
+1 [although de-duplication can save a lot of space, but AFAIK that isn't a feature of BTRFS, it is usually a feature of FUSE layers or SAN/NAS devices].
There are plenty of reasons why someone would have large amounts of text. Businesses, for instance.
Busnesses??? They have very little text. Even most PDFs are internally compresses. M$-Office documents aren't "text".
Incremental dumps makes backups much more efficient and effective.
And way more difficult to restore.
Linux is already suffering from a lack of good backup solutions.
+1 +1 +1
what? there are so many...
Really? Emphasis on "good" in "good backup solutions".
Just because there are lots of something doesn't mean any of them are particularly good. And even if they are, an improvement would still likely help a lot of people.
Having a decent and reliable UI would be a huge plus. And dealing with EA, xattrs, & ACLS - which most completely ignore.
And overall it will provide many of the features of LLVM directly in the filesystem. this is a good point. also the snapshot feature could be an enormous advantage if it works like VirtualBox snapshots. But is it really possible to be as flexible as that? Launching a snapshot for games and an other snapshot for work? I don't know, but I didn't mention snapshots at all because I don't know enough about them.
Snapshots still require the application(s) to be quiescent to be useful for restore. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Incremental dumps makes backups much more efficient and effective. Linux is already suffering from a lack of good backup solutions.
To be honest, I have my doubts. It's more like backup on every OS suffers from bad practice, not missing software features. I do not see that btrfs would heal this. -- Ralf Lang Linux Consultant / Developer B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Monday 14 March 2011 09:23:26 jdd wrote:
going where the most active developpers are?
As an aside, the most active development is usually in the most unfinished code. Anders -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 03/13/2011 03:21 PM, Bruno Friedmann wrote:
On 03/13/2011 05:12 PM, Per Jessen wrote:
Roman Bysh wrote:
Hi all,
Will we be seeing btrfs as the default file system in the next versions.
Which purpose would it serve?
There's really a lot's of area where btrfs will become usefull. ( some of them are only avalaible in ZFS actually ) But there's a lot of place to get it stabilize first. and missing important tools like a fsck like :-) Actually (My last check was one month ago) if a corrupt appear, you loose :-(
So I wouldn't see that as a default filesystem in openSUSE yet.
I've read: Michael Tso had remarked many times that it is the next logical progression. Linux was going to move from ext4 to btrfs. Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 03/14/2011 10:26 AM, Roman Bysh wrote:
On 03/13/2011 03:21 PM, Bruno Friedmann wrote:
On 03/13/2011 05:12 PM, Per Jessen wrote:
Roman Bysh wrote:
Hi all,
Will we be seeing btrfs as the default file system in the next versions.
Which purpose would it serve?
There's really a lot's of area where btrfs will become usefull. ( some of them are only avalaible in ZFS actually ) But there's a lot of place to get it stabilize first. and missing important tools like a fsck like :-) Actually (My last check was one month ago) if a corrupt appear, you loose :-(
So I wouldn't see that as a default filesystem in openSUSE yet.
I've read:
Michael Tso had remarked many times that it is the next logical progression.
Linux was going to move from ext4 to btrfs.
Roman Err. I meant Ted Tso.
-- Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 03/14/2011 10:26 AM, Roman Bysh wrote:
On 03/13/2011 03:21 PM, Bruno Friedmann wrote:
On 03/13/2011 05:12 PM, Per Jessen wrote:
Roman Bysh wrote:
Hi all,
Will we be seeing btrfs as the default file system in the next versions.
Which purpose would it serve?
There's really a lot's of area where btrfs will become usefull. ( some of them are only avalaible in ZFS actually ) But there's a lot of place to get it stabilize first. and missing important tools like a fsck like :-) Actually (My last check was one month ago) if a corrupt appear, you loose :-(
So I wouldn't see that as a default filesystem in openSUSE yet.
I've read:
Michael Tso had remarked many times that it is the next logical progression.
Linux was going to move from ext4 to btrfs.
Roman
Err. I meant Ted Tso. Even if Ted said btrfs is ready for production (which I don't think he does,
Am Montag, 14. März 2011 schrieb Roman Bysh: there aren't even stable releases of the tools yet) - how would you explain a user what he gets from the switch? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 03/14/2011 11:08 AM, Stephan Kulow wrote:
On 03/14/2011 10:26 AM, Roman Bysh wrote:
On 03/13/2011 03:21 PM, Bruno Friedmann wrote:
On 03/13/2011 05:12 PM, Per Jessen wrote:
Roman Bysh wrote:
Hi all,
Will we be seeing btrfs as the default file system in the next versions.
Which purpose would it serve?
There's really a lot's of area where btrfs will become usefull. ( some of them are only avalaible in ZFS actually ) But there's a lot of place to get it stabilize first. and missing important tools like a fsck like :-) Actually (My last check was one month ago) if a corrupt appear, you loose :-(
So I wouldn't see that as a default filesystem in openSUSE yet.
I've read:
Michael Tso had remarked many times that it is the next logical progression.
Linux was going to move from ext4 to btrfs.
Roman
Err. I meant Ted Tso. Even if Ted said btrfs is ready for production (which I don't think he does,
Am Montag, 14. März 2011 schrieb Roman Bysh: there aren't even stable releases of the tools yet) - how would you explain a user what he gets from the switch?
Greetings, Stephan I wouldn't say anything until some of these gotchas are addressed.
https://btrfs.wiki.kernel.org/index.php/Gotchas Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 03/13/2011 03:21 PM, Bruno Friedmann wrote:
On 03/13/2011 05:12 PM, Per Jessen wrote:
Roman Bysh wrote:
Hi all,
Will we be seeing btrfs as the default file system in the next versions.
Which purpose would it serve?
There's really a lot's of area where btrfs will become usefull. ( some of them are only avalaible in ZFS actually ) But there's a lot of place to get it stabilize first. and missing important tools like a fsck like :-) Actually (My last check was one month ago) if a corrupt appear, you loose :-(
So I wouldn't see that as a default filesystem in openSUSE yet.
ZFS would be great. Too bad Oracle owns it. -- Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 14/03/11 14:27, Roman Bysh wrote:
On 03/13/2011 03:21 PM, Bruno Friedmann wrote:
On 03/13/2011 05:12 PM, Per Jessen wrote:
Roman Bysh wrote:
Hi all,
Will we be seeing btrfs as the default file system in the next versions.
Which purpose would it serve?
There's really a lot's of area where btrfs will become usefull. ( some of them are only avalaible in ZFS actually ) But there's a lot of place to get it stabilize first. and missing important tools like a fsck like :-) Actually (My last check was one month ago) if a corrupt appear, you loose :-(
So I wouldn't see that as a default filesystem in openSUSE yet.
ZFS would be great. Too bad Oracle owns it.
Going back quite a while there was an article comparing ZFS and BTRFS. When mature BTRFS seems a better way to go. It was saiway back that Linus was using BTRFS as his root filesystem. I have ha it as a backup of my systems for a long time. On the Beagleboard (ARM) I shall be using it tomorrow as my root filesystem on Ubuntu ARM - as usual, while I was out today, the postman left a note to say he couldn't deliver my new 32Gig micro SD card I need to try it out. http://lwn.net/Articles/342892/ Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 03/14/2011 11:20 AM, Sid Boyce wrote:
On 14/03/11 14:27, Roman Bysh wrote:
On 03/13/2011 03:21 PM, Bruno Friedmann wrote:
On 03/13/2011 05:12 PM, Per Jessen wrote:
Roman Bysh wrote:
Hi all,
Will we be seeing btrfs as the default file system in the next versions.
Which purpose would it serve?
There's really a lot's of area where btrfs will become usefull. ( some of them are only avalaible in ZFS actually ) But there's a lot of place to get it stabilize first. and missing important tools like a fsck like :-) Actually (My last check was one month ago) if a corrupt appear, you loose :-(
So I wouldn't see that as a default filesystem in openSUSE yet.
ZFS would be great. Too bad Oracle owns it.
Going back quite a while there was an article comparing ZFS and BTRFS. When mature BTRFS seems a better way to go. It was saiway back that Linus was using BTRFS as his root filesystem. I have ha it as a backup of my systems for a long time. On the Beagleboard (ARM) I shall be using it tomorrow as my root filesystem on Ubuntu ARM - as usual, while I was out today, the postman left a note to say he couldn't deliver my new 32Gig micro SD card I need to try it out. http://lwn.net/Articles/342892/ Regards Sid.
Too bad about the micro card. Maybe tomorrow. My concerns are about power outages or if for some reason a "hard reset" may be required. -- Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 14/03/11 15:40, Roman Bysh wrote:
On 03/14/2011 11:20 AM, Sid Boyce wrote:
On 14/03/11 14:27, Roman Bysh wrote:
On 03/13/2011 03:21 PM, Bruno Friedmann wrote:
On 03/13/2011 05:12 PM, Per Jessen wrote:
Roman Bysh wrote:
Hi all,
Will we be seeing btrfs as the default file system in the next versions.
Which purpose would it serve?
There's really a lot's of area where btrfs will become usefull. ( some of them are only avalaible in ZFS actually ) But there's a lot of place to get it stabilize first. and missing important tools like a fsck like :-) Actually (My last check was one month ago) if a corrupt appear, you loose :-(
So I wouldn't see that as a default filesystem in openSUSE yet.
ZFS would be great. Too bad Oracle owns it.
Going back quite a while there was an article comparing ZFS and BTRFS. When mature BTRFS seems a better way to go. It was saiway back that Linus was using BTRFS as his root filesystem. I have ha it as a backup of my systems for a long time. On the Beagleboard (ARM) I shall be using it tomorrow as my root filesystem on Ubuntu ARM - as usual, while I was out today, the postman left a note to say he couldn't deliver my new 32Gig micro SD card I need to try it out. http://lwn.net/Articles/342892/ Regards Sid.
Too bad about the micro card. Maybe tomorrow. My concerns are about power outages or if for some reason a "hard reset" may be required.
So far I have had no problems after the box powered off with overtemperature problems. Th wiki you mentioned mentions 2.6.32 and 2.6.35 kernels which are pretty ancient now. There have been many updates since and even one in the latest 2.6.38-rc8-git4 kernel released today. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Sid Boyce
Going back quite a while there was an article comparing ZFS and BTRFS. When mature BTRFS seems a better way to go. It was saiway back that Linus was using BTRFS as his root filesystem. I have ha it as a backup of my systems for a long time. On the Beagleboard (ARM) I shall be using it tomorrow as my root filesystem on Ubuntu ARM - as usual, while I was out today, the postman left a note to say he couldn't deliver my new 32Gig micro SD card I need to try it out. http://lwn.net/Articles/342892/
Did you look at: "http://lwn.net/Articles/393144/"? Jörg -- EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin js@cs.tu-berlin.de (uni) joerg.schilling@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/14/2011 11:51 AM, Joerg Schilling wrote:
Sid Boyce
wrote: Going back quite a while there was an article comparing ZFS and BTRFS. When mature BTRFS seems a better way to go. It was saiway back that Linus was using BTRFS as his root filesystem. I have ha it as a backup of my systems for a long time. On the Beagleboard (ARM) I shall be using it tomorrow as my root filesystem on Ubuntu ARM - as usual, while I was out today, the postman left a note to say he couldn't deliver my new 32Gig micro SD card I need to try it out. http://lwn.net/Articles/342892/
Did you look at: "http://lwn.net/Articles/393144/"?
That article, especially the title, is just sensationalism. Edward's observations missed that btrfs does internal metadata duplication, so his numbers are off. He also points to a broken design as the root problem when, in fact, the issues he brought up were implementation issues. Edward, at the time, was also still actively working on reiser4 so I wouldn't discount the sour grapes effect[1]. It turns out that the two issues he mentioned, Fragmentation when using inline extents and Nearly empty nodes littering the file system are both implementation issues. The first is a feature that Chris thought the cost:benefit was too low to work on. The second was a bug in merging items. BTW, the wasted space issue is specious. There are workarounds to avoid the inline extent issue if you care about it. Yes, reiser[34] are exceptional at reducing wasted space with packed tails and packing items in well, but file systems are allowed to have different priorities. Not following reiser[34]'s priorities doesn't make it a design flaw. Other file systems waste loads of space in different ways. - -Jeff [1] The politics surrounding the inclusion of btrfs vs reiser4 are a topic for another discussion, but the short version is that if a project has a history of not working well with the broader Linux community, its chances of getting accepted into the mainline kernel are significantly reduced. - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1+PocACgkQLPWxlyuTD7LfhQCgmThTStkFpdEOjJet4NZ9pxUI wxQAn3j4NSXpWA41nQYWxbI8kVSVZ8eR =gM8d -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 03/14/2011 12:12 PM, Jeff Mahoney wrote:
On 03/14/2011 11:51 AM, Joerg Schilling wrote:
Sid Boyce
wrote: Going back quite a while there was an article comparing ZFS and BTRFS. When mature BTRFS seems a better way to go. It was saiway back that Linus was using BTRFS as his root filesystem. I have ha it as a backup of my systems for a long time. On the Beagleboard (ARM) I shall be using it tomorrow as my root filesystem on Ubuntu ARM - as usual, while I was out today, the postman left a note to say he couldn't deliver my new 32Gig micro SD card I need to try it out. http://lwn.net/Articles/342892/
Did you look at: "http://lwn.net/Articles/393144/"? That article, especially the title, is just sensationalism. Edward's observations missed that btrfs does internal metadata duplication, so his numbers are off. He also points to a broken design as the root problem when, in fact, the issues he brought up were implementation issues. Edward, at the time, was also still actively working on reiser4 so I wouldn't discount the sour grapes effect[1]. I agree. It is sour grapes. It turns out that the two issues he mentioned, Fragmentation when using inline extents and Nearly empty nodes littering the file system are both implementation issues. The first is a feature that Chris thought the cost:benefit was too low to work on. The second was a bug in merging items. BTW, the wasted space issue is specious. There are workarounds to avoid the inline extent issue if you care about it. Yes, reiser[34] are exceptional at reducing wasted space with packed tails and packing items in well, but file systems are allowed to have different priorities. Not following reiser[34]'s priorities doesn't make it a design flaw. Other file systems waste loads of space in different ways. A lot of those issues have already been addressed or will be this year. Including a fsck tool and defrag. -- Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Sonntag, 13. März 2011 schrieb Roman Bysh:
Hi all,
Will we be seeing btrfs as the default file system in the next versions.
Pending that it has matured enough.
I suggest someone invests time to adapt kiwi to use btrfs as file system within clicfs and then we can ask people to test. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/13/2011 10:29 AM, Roman Bysh wrote:
Hi all,
Will we be seeing btrfs as the default file system in the next versions.
For the next release, probably not. It could use some hammering, though, if you're up for doing that. Your best bet would be to use kernel-vanilla from Kernel:HEAD since that tracks the upstream btrfs code as closely as possible and will generate bug reports that the btrfs team will be interested in.
Pending that it has matured enough.
That's the hitch. It is getting more stable but still lacks basic error handling. If you've been using Linux long enough, think early versions of reiserfs (v3), where most errors were handled by panicking. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1+Jh8ACgkQLPWxlyuTD7K5KgCfQxToo1zGtTroeYotj5A99KDs zIkAn30d+75nRACowSzuOO2YatKUDA9p =wg+T -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 03/14/2011 10:28 AM, Jeff Mahoney wrote:
On 03/13/2011 10:29 AM, Roman Bysh wrote:
Hi all,
Will we be seeing btrfs as the default file system in the next versions.
For the next release, probably not. It could use some hammering, though, if you're up for doing that. Your best bet would be to use kernel-vanilla from Kernel:HEAD since that tracks the upstream btrfs code as closely as possible and will generate bug reports that the btrfs team will be interested in.
Pending that it has matured enough.
That's the hitch. It is getting more stable but still lacks basic error handling. If you've been using Linux long enough, think early versions of reiserfs (v3), where most errors were handled by panicking.
-Jeff
I've been using Linux since '99 and Minix much earlier. And yes, the reiserfs error (v3) panics were very memorable ;-) -Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/14/2011 11:08 AM, Roman Bysh wrote:
On 03/14/2011 10:28 AM, Jeff Mahoney wrote:
On 03/13/2011 10:29 AM, Roman Bysh wrote:
Hi all,
Will we be seeing btrfs as the default file system in the next versions.
For the next release, probably not. It could use some hammering, though, if you're up for doing that. Your best bet would be to use kernel-vanilla from Kernel:HEAD since that tracks the upstream btrfs code as closely as possible and will generate bug reports that the btrfs team will be interested in.
Pending that it has matured enough.
That's the hitch. It is getting more stable but still lacks basic error handling. If you've been using Linux long enough, think early versions of reiserfs (v3), where most errors were handled by panicking.
-Jeff
I've been using Linux since '99 and Minix much earlier. And yes, the reiserfs error (v3) panics were very memorable ;-)
BTW, I should also mention that I've been running my home server's data partition on btrfs for nearly a year now. I haven't had any hiccups with it. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAk1+gEoACgkQLPWxlyuTD7KEdgCffF5Z7S2mscVtaav8ZpCITnBq js0AniAi+F/aSqrZbVxQo602OYzVUBK+ =IRb6 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Mon, Mar 14, 2011 at 04:53:30PM -0400, Jeff Mahoney wrote:
On 03/14/2011 11:08 AM, Roman Bysh wrote:
On 03/14/2011 10:28 AM, Jeff Mahoney wrote:
On 03/13/2011 10:29 AM, Roman Bysh wrote:
Hi all,
Will we be seeing btrfs as the default file system in the next versions.
For the next release, probably not. It could use some hammering, though, if you're up for doing that. Your best bet would be to use kernel-vanilla from Kernel:HEAD since that tracks the upstream btrfs code as closely as possible and will generate bug reports that the btrfs team will be interested in.
Pending that it has matured enough.
That's the hitch. It is getting more stable but still lacks basic error handling. If you've been using Linux long enough, think early versions of reiserfs (v3), where most errors were handled by panicking.
-Jeff
I've been using Linux since '99 and Minix much earlier. And yes, the reiserfs error (v3) panics were very memorable ;-)
BTW, I should also mention that I've been running my home server's data partition on btrfs for nearly a year now. I haven't had any hiccups with it.
And, Novell has been shipping products that only use btrfs for over a year now (many many thousands of preload MeeGo systems) with no reported problems at all. thanks, greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Am Montag, 14. März 2011 schrieb Greg KH:
And, Novell has been shipping products that only use btrfs for over a year now (many many thousands of preload MeeGo systems) with no reported problems at all.
Well, there are _some_ reports :) https://bugs.meego.com/buglist.cgi?quicksearch=btrfs Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (21)
-
Adam Tauno Williams
-
Anders Johansson
-
Bruno Friedmann
-
Carl-Daniel Hailfinger
-
Eberhard Moenkeberg
-
Greg Freemyer
-
Greg KH
-
jdd
-
Jeff Mahoney
-
Joerg.Schilling@fokus.fraunhofer.de
-
Kim Leyendecker
-
Per Jessen
-
Peter Nikolic
-
Rajko M.
-
Ralf Lang
-
Roman Bysh
-
Sid Boyce
-
Stefan Seyfried
-
Stephan Kleine
-
Stephan Kulow
-
todd rme