subject:"Re\: Plans for BTRFS in Fedora"

On Tue, Feb 22, 2011 at 10:25 PM, Jon Masters jonat...@jonmasters.org wrote:
 On Tue, 2011-02-22 at 14:51 -0500, Josef Bacik wrote:

 2) Fedora 16 ships without LVM as the volume manager and instead use
 BTRFS's built in volume management, again just for the default.

 In my personal opinion, this is a poor design decision. Yes, BTRFS can
 do a lot of volume-y things, and these are growing by the day, but I
 don't want my filesystem replacing a full volume manager and I am
 concerned that this will lead to less testing and exposure to full LVM
 use within the Fedora community. Instead, I'd like to counter-propose
 that everything stay exactly as it is, with users being able to elect to
 switch to BTRFS (sub)volumes if they are interested in doing so.

 Should the switch to BTRFS by default happen, this will be one more
 thing I will have to fix immediately during installation. The list grows
 longer and longer over time - please don't make this change.


Theres no sense in using LVM if BTRFS can do the same job better.  I'm
not suggesting removing LVM altogether, just not using it for the
default pick the layout for me option, you can always do your own
thing with a custom layout.

Josef
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

On Tue, Feb 22, 2011 at 11:57 PM, Bruno Wolff III br...@wolff.to wrote:
 On Tue, Feb 22, 2011 at 14:51:50 -0500,
  Josef Bacik jo...@toxicpanda.com wrote:

 3) All the various little tools that we have for putting together
 LiveCD's that are very ext* centered.  I've not even looked at this
 yet, but I assume it's going to be kind of a pain.

 I like to see live CDs just use squashfs directly and not a squashed copy
 of an ext3/4 image. However this will break using dd to copy the image
 for installs which will slow things down. Further however, there is at least
 some interest in having live CDs and ananconda share the same install method,
 so this might be happening in any case.


This would be a great thing in general since the default ext* image is
shrunk down to be installed which creates a bad fs layout which has
performance implications.  Sure it may be faster for the install, but
overall it hurts our users.  So moving away from this dd an image
thing would be good for everybody.  Thanks,

Josef
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread drago01

On Wed, Feb 23, 2011 at 4:25 AM, Jon Masters jonat...@jonmasters.org wrote:
 On Tue, 2011-02-22 at 14:51 -0500, Josef Bacik wrote:

 2) Fedora 16 ships without LVM as the volume manager and instead use
 BTRFS's built in volume management, again just for the default.

 In my personal opinion, this is a poor design decision. Yes, BTRFS can
 do a lot of volume-y things, and these are growing by the day, but I
 don't want my filesystem replacing a full volume manager and I am
 concerned that this will lead to less testing and exposure to full LVM
 use within the Fedora community. Instead, I'd like to counter-propose
 that everything stay exactly as it is, with users being able to elect to
 switch to BTRFS (sub)volumes if they are interested in doing so.

 Should the switch to BTRFS by default happen, this will be one more
 thing I will have to fix immediately during installation. The list grows
 longer and longer over time - please don't make this change.

Oh god changes how dare we even think about those evil things!

Now seriously we cannot make progress when every time a (bigger)
change is proposed people start screaming but this changes what we
had before,
and regarding this particular case I think LVM by default has pretty
much always been a bad idea anyway.
And it is not like installing an OS is something you do everyday so
you install your OS, do the changes you think are necessary and be
done with it.
Defaults should be chooses on the metric what provides the best
experience for the users not based on what we have been doing in the
past (i.e stagnation).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Camilo Mesias

Hi

I wanted to second these questions...

2011/2/22 Jóhann B. johan...@gmail.com:
 Will there be any performance penalties making this move?
[...]
 What benefit will this switch bring to the novice desktop end users?

 Will the novice desktop end user ever take advantages of any of the features 
 that btrfs brings?

Since upgrading (downgrading?) my netbook to use an SSD I went with
the Anaconda defaults (using LVM etc) and that probably wasn't in my
best interest - judging from benchmarks at the time of read
performance in the LVM compared to the underlying device, also from
the point of not being able to add complex disk arrays to the netbook
any time soon.

I think Fedora could do more to support lower end devices *well*, in
addition to allowing people to use the very latest technology on
larger (ie. desktop and server) platforms. My impression right now is
I'd be interested to try BTRFS for the server and maybe larger
desktops, but would probably want to avoid it for anything smaller.

-Cam
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

On Wed, Feb 23, 2011 at 8:29 AM, Camilo Mesias cam...@mesias.co.uk wrote:
 Hi

 I wanted to second these questions...

 2011/2/22 Jóhann B. johan...@gmail.com:
 Will there be any performance penalties making this move?
 [...]
 What benefit will this switch bring to the novice desktop end users?

 Will the novice desktop end user ever take advantages of any of the features 
 that btrfs brings?

 Since upgrading (downgrading?) my netbook to use an SSD I went with
 the Anaconda defaults (using LVM etc) and that probably wasn't in my
 best interest - judging from benchmarks at the time of read
 performance in the LVM compared to the underlying device, also from
 the point of not being able to add complex disk arrays to the netbook
 any time soon.

 I think Fedora could do more to support lower end devices *well*, in
 addition to allowing people to use the very latest technology on
 larger (ie. desktop and server) platforms. My impression right now is
 I'd be interested to try BTRFS for the server and maybe larger
 desktops, but would probably want to avoid it for anything smaller.


Your impression is wrong, there has been quite a bit of work done to
make BTRFS work well on small devices, it is the default filesystem
for meego which goes on phones, which is much smaller than anything
you are going to have on your netbook.  Thanks,

Josef
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Camilo Mesias

Josef,

On Wed, Feb 23, 2011 at 1:42 PM, Josef Bacik jo...@toxicpanda.com wrote:
 Your impression is wrong, there has been quite a bit of work done to
 make BTRFS work well on small devices, it is the default filesystem
 for meego which goes on phones, which is much smaller than anything
 you are going to have on your netbook.  Thanks,

thanks for the info, I will be sure to test it when it is available.
My impression was based on a quick read of the BTRFS FAQ. I saw more
related to problems of limited disk space than to SSD support (but
granted, what mention there is sounds promising). I will test.

-Cam
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

On 02/22/2011 10:25 PM, Jon Masters wrote:
 On Tue, 2011-02-22 at 14:51 -0500, Josef Bacik wrote:
 
 2) Fedora 16 ships without LVM as the volume manager and instead use
 BTRFS's built in volume management, again just for the default.
 
 In my personal opinion, this is a poor design decision. Yes, BTRFS can
 do a lot of volume-y things, and these are growing by the day, but I
 don't want my filesystem replacing a full volume manager and I am
 concerned that this will lead to less testing and exposure to full LVM
 use within the Fedora community. Instead, I'd like to counter-propose
 that everything stay exactly as it is, with users being able to elect to
 switch to BTRFS (sub)volumes if they are interested in doing so.

I think this is more than a little bit over the top, but there are some
legitimate concerns we do need to keep track of and figure out solutions
to.  Off the top of my head, we need to figure out what we're doing with
encrypted volumes:

1) can btrfs do encrypted volumes?  Or, somewhat weirder but possibly better,
   encrypted volumes with non-encrypted subvolumes?
   a) if encrypted volumes but not plaintext subvolumes, then we need /boot
  split out to a separate physical partition, maybe
   b) if it can do encrypted subvolumes of non-encrypted volumes, we
  could make a /boot and a /sysroot and mount /sysroot as / I guess
   c) if no encrypted volumes, or if that functionality won't land at the
  same time as the basic parts, then we need to talk about UI for disk
  encryption:
  I) keeping lvm when encrypt data is checked in the anaconda UI,
 so we can continue to use luks on a VG in those cases.
  II) it may be worth investigating identifying machine classes during
  installation and varying the defaults based on them.  We talk about
  doing this every 3 or 4 releases for various reasons and usually
  decide it's a terrible idea and do something else.

 Should the switch to BTRFS by default happen, this will be one more
 thing I will have to fix immediately during installation. The list grows
 longer and longer over time - please don't make this change.

I think you're confusing necessity and desire here.

-- 
Peter

Computers don't make errors.  What they do, they do on purpose.
-- Dale
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread John Reiser

On 02/23/2011 05:07 AM, drago01 wrote:
 Defaults should be chooses on the metric what provides the best
 experience for the users not based on what we have been doing in the
 past (i.e stagnation).

*One* data corruption constitutes EPIC FAIL.  Btrfs is too young,
and will be for yet a while longer.

-- 
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

On Wed, Feb 23, 2011 at 9:18 AM, John Reiser jrei...@bitwagon.com wrote:
 On 02/23/2011 05:07 AM, drago01 wrote:
 Defaults should be chooses on the metric what provides the best
 experience for the users not based on what we have been doing in the
 past (i.e stagnation).

 *One* data corruption constitutes EPIC FAIL.  Btrfs is too young,
 and will be for yet a while longer.


Well if data corruption is the test then we shouldn't be using Ext4
either, there was one fixed as recently as the beginning of this
month.  File systems are software like anything else, there will be
bugs.  Off the top of my head I can think of 3 data corrupters we've
had in 4 years of working on BTRFS, and they've all been hard to hit
and have not to my knowledge been seen by users, only us developers in
testing.  BTRFS is young, but we have to start somewhere.  Thanks,

Josef
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Nathaniel McCallum

On Wed, 2011-02-23 at 09:27 -0500, Josef Bacik wrote:
 On Wed, Feb 23, 2011 at 9:18 AM, John Reiser jrei...@bitwagon.com wrote:
  On 02/23/2011 05:07 AM, drago01 wrote:
  Defaults should be chooses on the metric what provides the best
  experience for the users not based on what we have been doing in the
  past (i.e stagnation).
 
  *One* data corruption constitutes EPIC FAIL.  Btrfs is too young,
  and will be for yet a while longer.
 
 
 Well if data corruption is the test then we shouldn't be using Ext4
 either, there was one fixed as recently as the beginning of this
 month.  File systems are software like anything else, there will be
 bugs.  Off the top of my head I can think of 3 data corrupters we've
 had in 4 years of working on BTRFS, and they've all been hard to hit
 and have not to my knowledge been seen by users, only us developers in
 testing.  BTRFS is young, but we have to start somewhere.  Thanks,

From a user's perspective, I've been using btrfs for about 1.5 years on
multiple computers and I've been very happy (particularly on my netbook
where the transparent compression increases the disk writes
considerably).  I had one small problem where btrfs wouldn't mount, but
by booting off of a newer kernel I had no problems.

Thanks for your hard work on btrfs everyone!

Nathaniel

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

On 02/23/2011 03:27 PM, Josef Bacik wrote:
On Wed, Feb 23, 2011 at 9:18 AM, John Reiserjrei...@bitwagon.com wrote:
On 02/23/2011 05:07 AM, drago01 wrote:
Defaults should be chooses on the metric what provides the best
experience for the users not based on what we have been doing in the
past (i.e stagnation).

*One* data corruption constitutes EPIC FAIL. Btrfs is too young,
and will be for yet a while longer.

Well if data corruption is the test then we shouldn't be using Ext4
either, there was one fixed as recently as the beginning of this
month. File systems are software like anything else, there will be
bugs. Off the top of my head I can think of 3 data corrupters we've
had in 4 years of working on BTRFS, and they've all been hard to hit
and have not to my knowledge been seen by users, only us developers in
testing. BTRFS is young, but we have to start somewhere. Thanks,

I'm actually not that worried about corruption as that is something that
can be fixed once discovered. What creeps me out about btrfs at the moment
is this:

https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21__Btrfs_claims_I.27m_out_of_space.2C_but_it_looks_like_I_should_have_lots_left.21

The fact that the FS needs manual rebalance operations and that these can
take a while (even tough this can be done online) doesn't exactly make
btrfs the ideal candidate for an end-user desktop system that should pretty
much be able to look after itself.
I'm actually quite interested in btrfs especially for servers because of
it's features but this problem really worries me.

Regards,
Dennis
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Eric Sandeen

On 2/23/11 5:38 AM, Jóhann B. Guðmundsson wrote:
 On 02/23/2011 01:26 AM, Josef Bacik wrote:
 Various things, better data integrity to start with, and if you
 install the yum-fs-snapshot you have the ability to rollback easily.
 
 So we got the above + What Lennart mentioned as benefits to the end user.
 
 Now if we continue to hang on to the outdated concept ( From my 
 perspective ) of defaults as opposed to allowing each SIG to control 
 and set it's own defaults that suits their target end user base.
 
 For example any of the *DE might not want to switch to BTRFS until all 
 GUI tool for their end user to take advantage of what it has to offer 
 are in place while the Server SIG might certainly do.
 
 Hence I propose that we open a ticket with FESCO which will request them 
 to do something like this.
 
 Review the current filesystem default
 
 Gather feed back from various SIG with in the community to create a good 
 criteria for what needs to be in place in a filesystem for it to be 
 considered as an a default for Fedora.
 
 Gather a list of all existing linux filesystems ( there seems to be a 
 new one popping up every other month or so ).

Perhaps, but the list of possibly usable defaults for Fedora is not very long.

ext3, ext4, xfs, btrfs for now, I'd say.

Anything that popped up last month is not going to be ready for primetime
for years.

That said, I'd love to see it easy to tweak the default from among the supported
anaconda filesystems via kickstart or boot-time option, vs. having to go into
the detailed custom storage setup screen.  ext3 please is a lot simpler 
request
than custom partitioning with volume managers, and today it's all rolled into
one...

-Eric

 Filter out those that do not live up to that criteria and any base line 
 they set for their decision like must not perform worse then the 
 current default must work well on SSD's etc..  settle on one that 
 benefits most likely most the novice end users.
 ( We experienced users are able to choose tweak and turn any knob at 
 install time to suit our need which makes the novice end user the lowest 
 dominator)
 
 JBG

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

On Wed, Feb 23, 2011 at 10:19 AM, Dennis Jacobfeuerborn
denni...@conversis.de wrote:
On 02/23/2011 03:27 PM, Josef Bacik wrote:
On Wed, Feb 23, 2011 at 9:18 AM, John Reiserjrei...@bitwagon.com wrote:
On 02/23/2011 05:07 AM, drago01 wrote:
Defaults should be chooses on the metric what provides the best
experience for the users not based on what we have been doing in the
past (i.e stagnation).

*One* data corruption constitutes EPIC FAIL. Btrfs is too young,
and will be for yet a while longer.

I'm actually not that worried about corruption as that is something that
can be fixed once discovered. What creeps me out about btrfs at the moment
is this:

https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21__Btrfs_claims_I.27m_out_of_space.2C_but_it_looks_like_I_should_have_lots_left.21

Yes this is one of the more complicated areas of BTRFS and tends to
blow up in our faces a lot. That being said it's only a big deal if
you tend to run your filesystem close to full a lot, which most people
do not. It is an area that we work very hard to make sure it's not a
problem, hopefully we have eliminated all of the big problems and you
should really only see ENOSPC when you actually fill up the disk.
Thanks,

Josef
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Jóhann B. Guðmundsson

On 02/23/2011 03:33 PM, Josef Bacik wrote:

 I'm actually not that worried about corruption as that is something that
 can be fixed once discovered. What creeps me out about btrfs at the moment
 is this:

 https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21__Btrfs_claims_I.27m_out_of_space.2C_but_it_looks_like_I_should_have_lots_left.21

 The fact that the FS needs manual rebalance operations and that these can
 take a while (even tough this can be done online) doesn't exactly make
 btrfs the ideal candidate for an end-user desktop system that should pretty
 much be able to look after itself.
 I'm actually quite interested in btrfs especially for servers because of
 it's features but this problem really worries me.

 Yes this is one of the more complicated areas of BTRFS and tends to
 blow up in our faces a lot.  That being said it's only a big deal if
 you tend to run your filesystem close to full a lot, which most people
 do not.  It is an area that we work very hard to make sure it's not a
 problem, hopefully we have eliminated all of the big problems and you
 should really only see ENOSPC when you actually fill up the disk.
 Thanks,

I'm pretty sure for novice end user desktops the same procedure that 
would clean up old snapshot on regular intervals could make rebalance 
operation run at the same time since it can be done online...

JBG
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Simo Sorce

On Wed, 23 Feb 2011 10:33:26 -0500
Josef Bacik jo...@toxicpanda.com wrote:

On Wed, Feb 23, 2011 at 10:19 AM, Dennis Jacobfeuerborn
denni...@conversis.de wrote:
On 02/23/2011 03:27 PM, Josef Bacik wrote:
On Wed, Feb 23, 2011 at 9:18 AM, John Reiserjrei...@bitwagon.com
wrote:
On 02/23/2011 05:07 AM, drago01 wrote:
Defaults should be chooses on the metric what provides the best
experience for the users not based on what we have been doing
in the past (i.e stagnation).

*One* data corruption constitutes EPIC FAIL. Btrfs is too young,
and will be for yet a while longer.

Well if data corruption is the test then we shouldn't be using Ext4
either, there was one fixed as recently as the beginning of this
month. File systems are software like anything else, there will be
bugs. Off the top of my head I can think of 3 data corrupters
we've had in 4 years of working on BTRFS, and they've all been
hard to hit and have not to my knowledge been seen by users, only
us developers in testing. BTRFS is young, but we have to start
somewhere. Thanks,

I'm actually not that worried about corruption as that is something
that can be fixed once discovered. What creeps me out about btrfs
at the moment is this:

https://btrfs.wiki.kernel.org/index.php/FAQ#Help.21__Btrfs_claims_I.27m_out_of_space.2C_but_it_looks_like_I_should_have_lots_left.21

The fact that the FS needs manual rebalance operations and that
these can take a while (even tough this can be done online)
doesn't exactly make btrfs the ideal candidate for an end-user
desktop system that should pretty much be able to look after itself.
I'm actually quite interested in btrfs especially for servers
because of it's features but this problem really worries me.

Sorry josef,
but I do that all the time with my Virtual Machines, as I
do not give them more space then strictly needed.

I did that to the point that I needed to uninstall a few devel packages
in order to upgrade from f14 to rawhide on a VM ...

I am, not sure how common it is on a desktop, just wanted to point out
it is a use case to be able to run with little disk at least for
development VMs. (I guess I can manually run whatever tool there, as
long as it is clearly recognizable when I need to do so).

Simo.

--
Simo Sorce * Red Hat, Inc * New York
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Jon Masters

On Wed, 2011-02-23 at 07:15 -0500, Josh Boyer wrote:
 On Tue, Feb 22, 2011 at 10:25 PM, Jon Masters jonat...@jonmasters.org wrote:
  On Tue, 2011-02-22 at 14:51 -0500, Josef Bacik wrote:
 
  2) Fedora 16 ships without LVM as the volume manager and instead use
  BTRFS's built in volume management, again just for the default.
 
  In my personal opinion, this is a poor design decision. Yes, BTRFS can
  do a lot of volume-y things, and these are growing by the day, but I
  don't want my filesystem replacing a full volume manager and I am
  concerned that this will lead to less testing and exposure to full LVM
  use within the Fedora community. Instead, I'd like to counter-propose
  that everything stay exactly as it is, with users being able to elect to
  switch to BTRFS (sub)volumes if they are interested in doing so.
 
  Should the switch to BTRFS by default happen, this will be one more
  thing I will have to fix immediately during installation. The list grows
  longer and longer over time - please don't make this change.
 
 You seem to spend a lot of time during your installs undoing all the
 new things that were done for the release.  Perhaps a rapid changing,
 bleeding-edge distribution isn't quite suited to your needs.  Maybe
 you would be more comfortable with Debian or CentOS?

I'll bite. I am, indeed, a fan of various Enterprise Linux distributions
and I make no pretense that I am not. I do run an Enterprise Linux on
one desktop, and it's also true that I intentionally run my primary
desktop several Fedora releases behind so as to avoid many of the
problems I see from some of these changes. However, I also run more
recent Fedora releases, and on those releases, I typically have to undo
changes such as the one originally being proposed (replacing LVM).

Again, I feel the solution is to have a Fedora architect whose role is
to realize the problems caused by seemingly isolated changes, and stop
them from propagating. You don't just replace years of UNIX (or Linux)
history/heritage overnight without bothering a chunk of the users.

Jon.


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Lennart Poettering

On Wed, 23.02.11 11:41, Jon Masters (jonat...@jonmasters.org) wrote:

  You seem to spend a lot of time during your installs undoing all the
  new things that were done for the release.  Perhaps a rapid changing,
  bleeding-edge distribution isn't quite suited to your needs.  Maybe
  you would be more comfortable with Debian or CentOS?
 
 I'll bite. I am, indeed, a fan of various Enterprise Linux distributions
 and I make no pretense that I am not. I do run an Enterprise Linux on
 one desktop, and it's also true that I intentionally run my primary
 desktop several Fedora releases behind so as to avoid many of the
 problems I see from some of these changes. However, I also run more
 recent Fedora releases, and on those releases, I typically have to undo
 changes such as the one originally being proposed (replacing LVM).
 
 Again, I feel the solution is to have a Fedora architect whose role is
 to realize the problems caused by seemingly isolated changes, and stop
 them from propagating. You don't just replace years of UNIX (or Linux)
 history/heritage overnight without bothering a chunk of the users.

We have that already. It's called FESCO, and is pluralistic and
democratic and stuff.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

On 02/23/2011 11:41 AM, Jon Masters wrote:

 Again, I feel the solution is to have a Fedora architect whose role is
 to realize the problems caused by seemingly isolated changes, and stop
 them from propagating.

Fedora historically relies on an open source model for this - there
are a lot of smart people working on Fedora, and we depend on each and
every one of them to realize the problems caused by seemingly isolated
changes. With that in mind, I'm wondering if you have any input as to
what problems there might be with the change in question.

 You don't just replace years of UNIX (or Linux) history/heritage
 overnight without bothering a chunk of the users.

This is something what we've historically been willing to do in Linux,
and so far we've had pretty good results.

-- 
Peter

RFC 882 put the dots in .com.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Jesse Keating

On 2/23/11 5:00 AM, Josef Bacik wrote:
 This would be a great thing in general since the default ext* image is
 shrunk down to be installed which creates a bad fs layout which has
 performance implications.

Can you expand upon this more?  The filesystem is shrunk down when the 
live image is built, but then once it is installed the fs is resized to 
fill out the physical disk / partition it is being installed to.

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Lars Seipel

On Wednesday 23 February 2011 15:07:55 Peter Jones wrote:

 1) can btrfs do encrypted volumes?

Not yet.  Although this was a planned feature at some point, according to 
Josef, nobody has done it yet.

If you want to stack it on top of dm-crypt there are caveats as well.

From btrfs-wiki:
btrfs volumes on top of dm-crypt block devices (and possibly LVM) require
 write-caching to be turned off on the underlying HDD. Failing to do so, in
 the event of a power failure, may result in corruption not yet handled by
 btrfs code. (2.6.33)

Is this still prevailing as of 2.6.38?

While it may work if you're lucky (at least it did for me since F13) it can 
also munch your data. That's what happened to me last night in F15 (didn't 
lose any data though as such stuff was somewhat expected). Btrfs root partition 
(no LVM) on a dm-crypt volume on Intel 32 GB solid state drive.

After an unclean shutdown I was no longer able to mount the filesystem and 
therefore start the system. I even managed to crash a live system when trying 
to mount the decrypted luks volume containing the btrfs.

As I didn't have much time I just dd'ed an image to a spare disk and 
reinstalled. If there is any debugging value in this, I can make it available 
as long as I can be sure all data could be stripped from it (btrfs-image does 
exactly this, right?).

Be aware that the crash-on-shutdown didn't happen with an official Fedora 
kernel. Due to the update embargo on F15 I built an updated Kernel checked out 
with fedpkg.

If btrfs should become the default filesystem for Fedora (which I strongly 
support) a nice and clean solution for encrypted filesystems has to be found. 
Falling back to ext4  lvm when the encryption checkbox gets ticked is just 
plain ugly. Not supporting encrypted disks at all would be even worse.

Any ideas?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Eric Sandeen

On 2/23/11 11:42 AM, Jesse Keating wrote:
 On 2/23/11 5:00 AM, Josef Bacik wrote:
 This would be a great thing in general since the default ext* image is
 shrunk down to be installed which creates a bad fs layout which has
 performance implications.
 
 Can you expand upon this more?  The filesystem is shrunk down when the 
 live image is built, but then once it is installed the fs is resized to 
 fill out the physical disk / partition it is being installed to.

Shrinking down the filesystem tends to scramble it a bit.  All the allocator 
decisions that were made based on fs size at the time of install go out the 
window as resize2fs fills in every hole it can find to maximally compress the 
fs.

I haven't done a real analysis but I would expect that inode::data locality and 
filesystem fragmentation suffer as a result.

Resizing it back up after the install just attaches free space to the end of 
the shrunken fs.

-Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

On Wed, Feb 23, 2011 at 11:41:49AM -0500, Jon Masters wrote:

 Again, I feel the solution is to have a Fedora architect whose role is
 to realize the problems caused by seemingly isolated changes, and stop
 them from propagating. You don't just replace years of UNIX (or Linux)
 history/heritage overnight without bothering a chunk of the users.

LVM is functional for enterprise environments but awful for the common 
home or office cases. If btrfs lives up to its promises it'll give us 
something that provides pretty much all the functional beneft of LVM 
without the additional abstraction that makes seemingly straightforward 
tasks sufficiently awkward that even I find it abstruse (and I hack on 
ACPI). I think that's entirely in keeping with Linux heritage.

(AIX, on the other hand, delights in partying like it's 1979. Are you 
confusing the two?)

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Casey Dahlin

On Wed, Feb 23, 2011 at 11:54:58AM -0600, Eric Sandeen wrote:
 On 2/23/11 11:42 AM, Jesse Keating wrote:
  On 2/23/11 5:00 AM, Josef Bacik wrote:
  This would be a great thing in general since the default ext* image is
  shrunk down to be installed which creates a bad fs layout which has
  performance implications.
  
  Can you expand upon this more?  The filesystem is shrunk down when the 
  live image is built, but then once it is installed the fs is resized to 
  fill out the physical disk / partition it is being installed to.
 
 Shrinking down the filesystem tends to scramble it a bit.  All the allocator
 decisions that were made based on fs size at the time of install go out the
 window as resize2fs fills in every hole it can find to maximally compress the
 fs.
 

Is there some sort of sparsifying defrag we could do after copying the image
over? The dd-based install is so fast that we could actually afford another
pass if we needed it IMHO.

--CJD
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Eric Sandeen

On 2/23/11 12:15 PM, Casey Dahlin wrote:
 On Wed, Feb 23, 2011 at 11:54:58AM -0600, Eric Sandeen wrote:
 On 2/23/11 11:42 AM, Jesse Keating wrote:
 On 2/23/11 5:00 AM, Josef Bacik wrote:
 This would be a great thing in general since the default ext* image is
 shrunk down to be installed which creates a bad fs layout which has
 performance implications.

 Can you expand upon this more?  The filesystem is shrunk down when the 
 live image is built, but then once it is installed the fs is resized to 
 fill out the physical disk / partition it is being installed to.

 Shrinking down the filesystem tends to scramble it a bit.  All the allocator
 decisions that were made based on fs size at the time of install go out the
 window as resize2fs fills in every hole it can find to maximally compress the
 fs.

 
 Is there some sort of sparsifying defrag we could do after copying the image
 over? The dd-based install is so fast that we could actually afford another
 pass if we needed it IMHO.

Not really... e4defrag could maybe, in theory, but its still pretty unloved.

I wonder how it'd go to prep the install on a sparse image of some reasonable 
size,
and then do an efficient sparse copy of that onto the target.  That would save 
the
scrambling, at least, and still give us minimum space usage on the install disc.

-Eric
 
 --CJD

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

On 02/23/2011 01:15 PM, Casey Dahlin wrote:
 On Wed, Feb 23, 2011 at 11:54:58AM -0600, Eric Sandeen wrote:
 On 2/23/11 11:42 AM, Jesse Keating wrote:
 On 2/23/11 5:00 AM, Josef Bacik wrote:
 This would be a great thing in general since the default ext* image is
 shrunk down to be installed which creates a bad fs layout which has
 performance implications.

 Can you expand upon this more?  The filesystem is shrunk down when the
 live image is built, but then once it is installed the fs is resized to
 fill out the physical disk / partition it is being installed to.

 Shrinking down the filesystem tends to scramble it a bit.  All the allocator
 decisions that were made based on fs size at the time of install go out the
 window as resize2fs fills in every hole it can find to maximally compress the
 fs.


 Is there some sort of sparsifying defrag we could do after copying the image
 over? The dd-based install is so fast that we could actually afford another
 pass if we needed it IMHO.

Just as soon as you write it ;)

-- 
 Peter

RFC 882 put the dots in .com.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

On 02/23/2011 12:50 PM, Lars Seipel wrote:
 On Wednesday 23 February 2011 15:07:55 Peter Jones wrote:
 
 1) can btrfs do encrypted volumes?
 
 Not yet.  Although this was a planned feature at some point, according to
 Josef, nobody has done it yet.
 
 If you want to stack it on top of dm-crypt there are caveats as well.

Right, which is what we'd wind up doing in the encrypted case.

 From btrfs-wiki:
 btrfs volumes on top of dm-crypt block devices (and possibly LVM) require
 write-caching to be turned off on the underlying HDD. Failing to do so, in
 the event of a power failure, may result in corruption not yet handled by
 btrfs code. (2.6.33)
 
 Is this still prevailing as of 2.6.38?

So, don't hold me to this, but it looks as if the normal lvm behaviour was
fixed at least as of d87f4c14f2 .  That being said, dm-crypt still just throws
REQ_FLUSH away instead of figuring out the block remaps involved and issuing
the right bios. Of course, this is a problem with dm-crypt and _any_ filesystem.

-- 
Peter

RFC 882 put the dots in .com.

01234567890123456789012345678901234567890123456789012345678901234567890123456789
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

BTRFS on servers (was Re: Plans for BTRFS in Fedora)

2011-02-23 Thread Jonathan Dieter

On Wed, 2011-02-23 at 16:19 +0100, Dennis Jacobfeuerborn wrote:
 I'm actually quite interested in btrfs especially for servers because
 of it's features

For what it's worth, we've been running btrfs on our school fileservers
since September.  After a few teething problems (fixed by
increasing /proc/sys/vm/min_free_kbytes), we've had pretty much zero
trouble.

The best part is we no longer need LVM on those servers and we get the
benefit of painless snapshot generation (we tried LVM snapshots and they
were *slow*).

Jonathan


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BTRFS on servers (was Re: Plans for BTRFS in Fedora)

On Wed, Feb 23, 2011 at 2:00 PM, Jonathan Dieter jdie...@lesbg.com wrote:
 On Wed, 2011-02-23 at 16:19 +0100, Dennis Jacobfeuerborn wrote:
 I'm actually quite interested in btrfs especially for servers because
 of it's features

 For what it's worth, we've been running btrfs on our school fileservers
 since September.  After a few teething problems (fixed by
 increasing /proc/sys/vm/min_free_kbytes), we've had pretty much zero
 trouble.


Wait what?  I know we use lots o ram, but you shouldn't have to bump
min_free_kbytes.  What were you seeing?  Thanks,

Josef
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

Once upon a time, Matthew Garrett mj...@srcf.ucam.org said:
 LVM is functional for enterprise environments but awful for the common 
 home or office cases.

Define awful.  I make use of it all the time on home and office
desktops and even my notebook computer.  It makes it easy to reassign
disk space from purpose A to purpose B (it would be easier if there was
a way to shrink a mounted ext3/ext4 FS, but that's a hard problem).
Logical volumes for virtual machines perform better (and virtualization
is something becoming more common on the desktop for compatibility).

-- 
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BTRFS on servers (was Re: Plans for BTRFS in Fedora)

2011-02-23 Thread Jonathan Dieter

On Wed, 2011-02-23 at 14:18 -0500, Josef Bacik wrote:
 On Wed, Feb 23, 2011 at 2:00 PM, Jonathan Dieter jdie...@lesbg.com wrote:
  On Wed, 2011-02-23 at 16:19 +0100, Dennis Jacobfeuerborn wrote:
  I'm actually quite interested in btrfs especially for servers because
  of it's features
 
  For what it's worth, we've been running btrfs on our school fileservers
  since September.  After a few teething problems (fixed by
  increasing /proc/sys/vm/min_free_kbytes), we've had pretty much zero
  trouble.
 
 
 Wait what?  I know we use lots o ram, but you shouldn't have to bump
 min_free_kbytes.  What were you seeing?  Thanks,

Sorry, I didn't mean to imply it was btrfs that was causing the problem.
We got new servers when we did our upgrade and ran into problems with
the e1000e kernel module being unable to allocate memory even though
there was loads free.  Bumping up min_free_kbytes fixed it.

See https://bugzilla.redhat.com/show_bug.cgi?id=626851 for more detail.

Jonathan


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

On Wed, Feb 23, 2011 at 01:38:05PM -0600, Chris Adams wrote:

 Define awful.  I make use of it all the time on home and office
 desktops and even my notebook computer.  It makes it easy to reassign
 disk space from purpose A to purpose B (it would be easier if there was
 a way to shrink a mounted ext3/ext4 FS, but that's a hard problem).
 Logical volumes for virtual machines perform better (and virtualization
 is something becoming more common on the desktop for compatibility).

You can't move PVs. You need a separate /boot. If you use more than one 
disk then it adds significant fragility to the boot process. It slows 
down booting. It provides some functionality that's hugely useful in a 
small number of cases, and in every other case it just makes your life 
more complicated. btrfs does the former without anywhere near as much of 
the latter.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

On Wed, Feb 23, 2011 at 07:49:49PM +, Matthew Garrett wrote:

 You can't move PVs. You need a separate /boot. If you use more than one 
 disk then it adds significant fragility to the boot process. It slows 
 down booting. It provides some functionality that's hugely useful in a 
 small number of cases, and in every other case it just makes your life 
 more complicated. btrfs does the former without anywhere near as much of 
 the latter.

Also, the management tools are worse than AIX had in 1992. I'll accept 
that that's not an inherent flaw in the implementation, merely an 
inconvenient aspect of reality.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: BTRFS on servers (was Re: Plans for BTRFS in Fedora)

On Wed, Feb 23, 2011 at 2:42 PM, Jonathan Dieter jdie...@lesbg.com wrote:
 On Wed, 2011-02-23 at 14:18 -0500, Josef Bacik wrote:
 On Wed, Feb 23, 2011 at 2:00 PM, Jonathan Dieter jdie...@lesbg.com wrote:
  On Wed, 2011-02-23 at 16:19 +0100, Dennis Jacobfeuerborn wrote:
  I'm actually quite interested in btrfs especially for servers because
  of it's features
 
  For what it's worth, we've been running btrfs on our school fileservers
  since September.  After a few teething problems (fixed by
  increasing /proc/sys/vm/min_free_kbytes), we've had pretty much zero
  trouble.
 

 Wait what?  I know we use lots o ram, but you shouldn't have to bump
 min_free_kbytes.  What were you seeing?  Thanks,

 Sorry, I didn't mean to imply it was btrfs that was causing the problem.
 We got new servers when we did our upgrade and ran into problems with
 the e1000e kernel module being unable to allocate memory even though
 there was loads free.  Bumping up min_free_kbytes fixed it.

 See https://bugzilla.redhat.com/show_bug.cgi?id=626851 for more detail.


Ah ok, good, nevermind then :),

Joesf
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

Once upon a time, Matthew Garrett mj...@srcf.ucam.org said:
 You can't move PVs.

What do you think pvmove does?

 You need a separate /boot.

That's needed for more than just LVM (and probably won't go away, as it
is a lot simpler to handle a single method in the installer).

 If you use more than one 
 disk then it adds significant fragility to the boot process.

How does it do that (any more than any other multi-disk setup)?

 It slows 
 down booting.

Cite numbers?  It was slower early on, but it goes right by now.  I
don't doubt it adds some time (of course), but I don't see it being any
significant amount.

 It provides some functionality that's hugely useful in a 
 small number of cases, and in every other case it just makes your life 
 more complicated.

For most, it doesn't make things any more complicated (because they
never touch it).  I'd say that LVM is useful in a growing number of
cases.

 btrfs does the former without anywhere near as much of 
 the latter.

Oh, I don't object to btrfs and having the basic volume management in
the filesystem layer.  AdvFS on DEC Unix was great in that respect.  I
object to your painting of LVM aw awful.
-- 
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

2011-02-23 Thread Ralf Ertzinger

Hi.

On Wed, 23 Feb 2011 13:38:05 -0600, Chris Adams wrote

 Define awful.  I make use of it all the time on home and office
 desktops and even my notebook computer.  It makes it easy to reassign
 disk space from purpose A to purpose B (it would be easier if there
 was a way to shrink a mounted ext3/ext4 FS, but that's a hard
 problem). Logical volumes for virtual machines perform better (and
 virtualization is something becoming more common on the desktop for
 compatibility).

If you never tried the kind of freedom BTRFS and ZFS give you for
shifting around disk space, try it. Seriously. Then you'll see where
the awful comes from. In perspective it really is.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

On Wed, Feb 23, 2011 at 02:08:08PM -0600, Chris Adams wrote:
 Once upon a time, Matthew Garrett mj...@srcf.ucam.org said:
  You can't move PVs.
 
 What do you think pvmove does?

Move PEs from one PV to another. You can't move a PV.

  You need a separate /boot.
 
 That's needed for more than just LVM (and probably won't go away, as it
 is a lot simpler to handle a single method in the installer).

Unless you're booting off iSCSI or really, really love software RAID 
(which btrfs also kindly simplifies), the only reason you need a 
separate /boot is because we're slow at putting updated filesystem 
support in grub because there's no need because we default to a separate 
/boot. There's a certain amount of circularity there.

  If you use more than one 
  disk then it adds significant fragility to the boot process.
 
 How does it do that (any more than any other multi-disk setup)?

My experience with LVM is that any number of error states dump me into 
an awkward recovery scenario. Again it's not an inherent problem with 
the technology, more just that because nobody outside the enterprise 
world really cares about LVM nobody has bothered making it easy for 
non-sysadmins to handle this stuff.

  It slows 
  down booting.
 
 Cite numbers?  It was slower early on, but it goes right by now.  I
 don't doubt it adds some time (of course), but I don't see it being any
 significant amount.

Talk to Lennart about it. It's on the order of two seconds.

  btrfs does the former without anywhere near as much of 
  the latter.
 
 Oh, I don't object to btrfs and having the basic volume management in
 the filesystem layer.  AdvFS on DEC Unix was great in that respect.  I
 object to your painting of LVM aw awful.

My objections to the technology aren't that strong. My objections to the 
user experience are.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

On 02/23/2011 03:33 PM, Matthew Garrett wrote:
 On Wed, Feb 23, 2011 at 02:08:08PM -0600, Chris Adams wrote:
 Once upon a time, Matthew Garrettmj...@srcf.ucam.org  said:
 You can't move PVs.

 What do you think pvmove does?

 Move PEs from one PV to another. You can't move a PV.

 You need a separate /boot.

 That's needed for more than just LVM (and probably won't go away, as it
 is a lot simpler to handle a single method in the installer).

 Unless you're booting off iSCSI or really, really love software RAID
 (which btrfs also kindly simplifies), the only reason you need a
 separate /boot is because we're slow at putting updated filesystem
 support in grub because there's no need because we default to a separate
 /boot. There's a certain amount of circularity there.

Also we need to have the initramfs on an unencrypted chunk of disk.

 If you use more than one
 disk then it adds significant fragility to the boot process.

 How does it do that (any more than any other multi-disk setup)?

 My experience with LVM is that any number of error states dump me into
 an awkward recovery scenario. Again it's not an inherent problem with
 the technology, more just that because nobody outside the enterprise
 world really cares about LVM nobody has bothered making it easy for
 non-sysadmins to handle this stuff.

Yep.

-- 
 Peter

RFC 882 put the dots in .com.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

Once upon a time, Matthew Garrett mj...@srcf.ucam.org said:
 On Wed, Feb 23, 2011 at 02:08:08PM -0600, Chris Adams wrote:
  Once upon a time, Matthew Garrett mj...@srcf.ucam.org said:
   You can't move PVs.
  
  What do you think pvmove does?
 
 Move PEs from one PV to another. You can't move a PV.

Not exactly; pvmove moves data from one PE to another (either in another
PV or in the same PV).  I guess I don't understand your original
objection though.  You can move data around within a PV (granted the
command usage to do this is non-obvious and it would be good for that to
improve, but it is also not a common use case) and from one PV to
another; what else is there to move?

   You need a separate /boot.
  
  That's needed for more than just LVM (and probably won't go away, as it
  is a lot simpler to handle a single method in the installer).
 
 Unless you're booting off iSCSI or really, really love software RAID 
 (which btrfs also kindly simplifies),

Using software RAID means really, really love it?  How else do you
propose to boot from software RAID (if you just kinda like it)?  We're
talking about the typical home/office desktop, so you aren't going to
have hardware RAID, and Linux software RAID is superior to motherboard
software RAID.

 the only reason you need a 
 separate /boot is because we're slow at putting updated filesystem 
 support in grub because there's no need because we default to a separate 
 /boot. There's a certain amount of circularity there.

Encrypted root filesystem requires a separate (non-encrypted) /boot, and
I think that's only going to increase in popularity (especially on
notebooks and other mobile devices).

 My experience with LVM is that any number of error states dump me into 
 an awkward recovery scenario.

I guess in the years I've used LVM, I haven't run into that any number
of error states (at least AFAIK, but since you didn't identify any of
them, it is hard to say).  Sure, when LVM was new, I had to learn a few
more commands to handle the system didn't boot case, but IIRC only
once was that related to LVM (and that was because I renamed a VG
without rebuilding the initrd, which may be no longer an issue with
dracut).

If you don't know what you are doing, just fsck is going to be a
problem.  That's an issue with documentation and maybe making better
recovery tools, not LVM.  Adding a new set of commands to learn with
BTRFS isn't magically going to make it easier; you still have to learn
new stuff.

-- 
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora

Once upon a time, Ralf Ertzinger fed...@camperquake.de said:
 If you never tried the kind of freedom BTRFS and ZFS give you for
 shifting around disk space, try it. Seriously. Then you'll see where
 the awful comes from. In perspective it really is.

You cut out the parts of my email where I said I don't have any problem
with BTRFS, and I look forward to it making things better.  As I said, I
used AdvFS on DEC Unix for many years; ZFS and BTRFS are late-comers to
the filesystem/LVM party (although they obviously bring more to the
table).

-- 
Chris Adams cmad...@hiwaay.net
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Plans for BTRFS in Fedora