2:53 a.m.
Hallo,
for Fedora 17 we had a feature to make btrfs to the
standard filesystem of Fedora. This feature was defered
because the fsck utitlities for btrfs was not available
on the stable state for Fedora 17.
So, I would like to ask, if there any plans to make this to
a feautre for F-19. I think it may be sense to integreate
this feature to the rewrite of the part of anaconde which
is responsible for disc partitioning. In a article of the
c't magazin (a german computer magazin) I could read, that
this part of the new release of anaconda may be get any
more love.
Additionally, because I have read about an issue relating
btrfs with LVM2 on this mailing list and lost the thread, I
woould like to ask about the starte of this issue.
Best Regards:
Jochen Schmitt
6:18 a.m.
On Wed, Jan 16, 2013 at 09:53:25AM +0100, Jochen Schmitt wrote:
Hallo,
for Fedora 17 we had a feature to make btrfs to the
standard filesystem of Fedora. This feature was defered
because the fsck utitlities for btrfs was not available
on the stable state for Fedora 17.
So, I would like to ask, if there any plans to make this to
a feautre for F-19. I think it may be sense to integreate
this feature to the rewrite of the part of anaconde which
is responsible for disc partitioning. In a article of the
c't magazin (a german computer magazin) I could read, that
this part of the new release of anaconda may be get any
more love.
Additionally, because I have read about an issue relating
btrfs with LVM2 on this mailing list and lost the thread, I
woould like to ask about the starte of this issue.
So there are a couple of issues with btrfs which I believe absolutely
must be fixed before it can become the default (both affect
virtualization, coincidentally):
https://bugzilla.redhat.com/show_bug.cgi?id=863978
(data corruptor -- very serious IMHO, and it's been around for *months*)
https://bugzilla.redhat.com/show_bug.cgi?id=689127
(performance problem with virtual machines)
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
7:22 a.m.
On Wed, 16 Jan 2013 13:18:19 +0100, Richard W.M. Jones wrote:
So there are a couple of issues with btrfs which I believe
absolutely
must be fixed before it can become the default (both affect
virtualization, coincidentally):
It affects also compilation, GDB was rebuilding for 10-15 minutes instead of
< 1 minute. I have provided even a reproducer for 1sec vs. 1min issue.
The Bug just got automatically closed without any human reply as almost all of
the kernel bugs.
btrfs: poor performance
https://bugzilla.redhat.com/show_bug.cgi?id=759304
I have filed more Bugs why btrfs is unusable, I had to switch back both my
hosts to ext4:
btrfs: No space left on device with 21GB available
https://bugzilla.redhat.com/show_bug.cgi?id=857435
(after conversion to ext4 I had 50GB free on 150GB disk)
btrfs: Random `No such file or directory' on files not being changed at all
https://bugzilla.redhat.com/show_bug.cgi?id=759426
upstream kernel: btrfsctl -r: crash
https://bugzilla.redhat.com/show_bug.cgi?id=830564
btrfs: general protection fault: set_extent_dirty
https://bugzilla.redhat.com/show_bug.cgi?id=889775
Regards,
Jan
10:04 a.m.
On Wed, Jan 16, 2013 at 8:22 AM, Jan Kratochvil
<jan.kratochvil(a)redhat.com>wrote:
It affects also compilation, GDB was rebuilding for 10-15 minutes instead
of
< 1 minute. I have provided even a reproducer for 1sec vs. 1min issue.
The Bug just got automatically closed without any human reply as almost
all of
the kernel bugs.
btrfs: poor performance
https://bugzilla.redhat.com/show_bug.cgi?id=759304
I have filed more Bugs why btrfs is unusable, I had to switch back both my
hosts to ext4:
btrfs: No space left on device with 21GB available
https://bugzilla.redhat.com/show_bug.cgi?id=857435
(after conversion to ext4 I had 50GB free on 150GB disk)
btrfs: Random `No such file or directory' on files not being
changed at all
https://bugzilla.redhat.com/show_bug.cgi?id=759426
upstream kernel: btrfsctl -r: crash
https://bugzilla.redhat.com/show_bug.cgi?id=830564
btrfs: general protection fault: set_extent_dirty
https://bugzilla.redhat.com/show_bug.cgi?id=889775
These should probably just filed upstream. Josef Bacik left Red Hat and
joined fusionio along with Chris Mason. I don't know if anyone else within
Red Hat is working on Btrfs
Rahul
10:23 a.m.
On 1/16/13 10:04 AM, Rahul Sundaram wrote:
On Wed, Jan 16, 2013 at 8:22 AM, Jan Kratochvil <jan.kratochvil(a)redhat.com
<mailto:jan.kratochvil@redhat.com>> wrote:
It affects also compilation, GDB was rebuilding for 10-15 minutes instead of
< 1 minute. I have provided even a reproducer for 1sec vs. 1min issue.
The Bug just got automatically closed without any human reply as almost all of
the kernel bugs.
btrfs: poor performance
https://bugzilla.redhat.com/show_bug.cgi?id=759304
I have filed more Bugs why btrfs is unusable, I had to switch back both my
hosts to ext4:
btrfs: No space left on device with 21GB available
https://bugzilla.redhat.com/show_bug.cgi?id=857435
(after conversion to ext4 I had 50GB free on 150GB disk)
btrfs: Random `No such file or directory' on files not being changed at
all
https://bugzilla.redhat.com/show_bug.cgi?id=759426
upstream kernel: btrfsctl -r: crash
https://bugzilla.redhat.com/show_bug.cgi?id=830564
btrfs: general protection fault: set_extent_dirty
https://bugzilla.redhat.com/show_bug.cgi?id=889775
These should probably just filed upstream. Josef Bacik left Red Hat
and joined fusionio along with Chris Mason. I don't know if anyone
else within Red Hat is working on Btrfs
Zach Brown is, and I'm trying to get more involved as well.
TBH I don't know that upstream would receive any more attention.
-Eric
Rahul
10:41 a.m.
On 01/16/2013 04:23 PM, Eric Sandeen wrote:
On 1/16/13 10:04 AM, Rahul Sundaram wrote:
>
>
> On Wed, Jan 16, 2013 at 8:22 AM, Jan Kratochvil <jan.kratochvil(a)redhat.com
<mailto:jan.kratochvil@redhat.com>> wrote:
>
>
> It affects also compilation, GDB was rebuilding for 10-15 minutes instead of
> < 1 minute. I have provided even a reproducer for 1sec vs. 1min issue.
> The Bug just got automatically closed without any human reply as almost all of
> the kernel bugs.
> btrfs: poor performance
> https://bugzilla.redhat.com/show_bug.cgi?id=759304
>
> I have filed more Bugs why btrfs is unusable, I had to switch back both my
> hosts to ext4:
> btrfs: No space left on device with 21GB available
> https://bugzilla.redhat.com/show_bug.cgi?id=857435
> (after conversion to ext4 I had 50GB free on 150GB disk)
> btrfs: Random `No such file or directory' on files not being changed
at all
> https://bugzilla.redhat.com/show_bug.cgi?id=759426
> upstream kernel: btrfsctl -r: crash
> https://bugzilla.redhat.com/show_bug.cgi?id=830564
> btrfs: general protection fault: set_extent_dirty
> https://bugzilla.redhat.com/show_bug.cgi?id=889775
>
>
> These should probably just filed upstream. Josef Bacik left Red Hat
> and joined fusionio along with Chris Mason. I don't know if anyone
> else within Red Hat is working on Btrfs
Zach Brown is, and I'm trying to get more involved as well.
TBH I don't know that upstream would receive any more attention.
Afik Josef just left Red Hat not Fedora...
JBG
11:08 a.m.
I am testing btrfs on kvm guest, currently i have found:
* Bug 894837 - Transient / Intermittent ENOSPC errors with BTRFS and F18
(btrfs gives no space left on device at full or near full filesystem
and heavy io, for example deleting stuff to reclaim space.)
11:16 a.m.
On Wed, Jan 16, 2013 at 12:00 PM, Rahul Sundaram <metherid(a)gmail.com> wrote:
On Wed, Jan 16, 2013 at 11:41 AM, "Jóhann B. Guðmundsson" wrote:
>
> Afik Josef just left Red Hat not Fedora...
I haven't seen any recent activity in Fedora from him. Have you?
Did you see consistent activity in Fedora while I was at Red Hat? Because
that would be news to me ;)
Josef
10:03 a.m.
On 01/16/2013 11:41 AM, "Jóhann B. Guðmundsson" wrote:
On 01/16/2013 04:23 PM, Eric Sandeen wrote:
> On 1/16/13 10:04 AM, Rahul Sundaram wrote:
>>
>>
>> On Wed, Jan 16, 2013 at 8:22 AM, Jan Kratochvil <jan.kratochvil(a)redhat.com
>> <mailto:jan.kratochvil@redhat.com>> wrote:
>>
>>
>> It affects also compilation, GDB was rebuilding for 10-15 minutes
>> instead of
>> < 1 minute. I have provided even a reproducer for 1sec vs. 1min issue.
>> The Bug just got automatically closed without any human reply as almost
>> all of
>> the kernel bugs.
>> btrfs: poor performance
>> https://bugzilla.redhat.com/show_bug.cgi?id=759304
>>
>> I have filed more Bugs why btrfs is unusable, I had to switch back both my
>> hosts to ext4:
>> btrfs: No space left on device with 21GB available
>> https://bugzilla.redhat.com/show_bug.cgi?id=857435
>> (after conversion to ext4 I had 50GB free on 150GB disk)
>> btrfs: Random `No such file or directory' on files not being
>> changed at all
>> https://bugzilla.redhat.com/show_bug.cgi?id=759426
>> upstream kernel: btrfsctl -r: crash
>> https://bugzilla.redhat.com/show_bug.cgi?id=830564
>> btrfs: general protection fault: set_extent_dirty
>> https://bugzilla.redhat.com/show_bug.cgi?id=889775
>>
>>
>> These should probably just filed upstream. Josef Bacik left Red Hat
>> and joined fusionio along with Chris Mason. I don't know if anyone
>> else within Red Hat is working on Btrfs
> Zach Brown is, and I'm trying to get more involved as well.
>
> TBH I don't know that upstream would receive any more attention.
Afik Josef just left Red Hat not Fedora...
JBG
Correct, Josef still works on upstream btrfs & we have a lot of upstream
developers (some employed by Red Hat) working on btrfs.
I do agree that we need to be very clear about the quality bar needed to flip
the default file system over to btrfs.
I think it is probably worth putting together an updated Fedora Feature page to
lay out what exactly we need.
Ric
12:12 p.m.
So there are a couple of issues with btrfs which I believe
absolutely
must be fixed before it can become the default
I'd agree, though I'd have a different list of pet bugs.
But that's a subjective judgement. I'd be the first to admit that I'm
pretty risk averse, especially when it comes to losing data and
rendering machines unbootable.
Is there an existing set of criteria that Fedora would use to determine
that btrfs is sufficiently reliable to use as the default for new
installs?
- z
12:24 p.m.
On Wed, Jan 16, 2013 at 1:12 PM, Zach Brown <zab(a)zabbo.net> wrote:
> So there are a couple of issues with btrfs which I believe
absolutely
> must be fixed before it can become the default
I'd agree, though I'd have a different list of pet bugs.
But that's a subjective judgement. I'd be the first to admit that I'm
pretty risk averse, especially when it comes to losing data and
rendering machines unbootable.
Is there an existing set of criteria that Fedora would use to determine
that btrfs is sufficiently reliable to use as the default for new
installs?
Not really. The de facto criteria would be "as stable as the current
default", which is ext4. That is also somewhat subjective.
josh
12:50 p.m.
On Wed, Jan 16, 2013 at 10:12:34AM -0800, Zach Brown wrote:
> So there are a couple of issues with btrfs which I believe
absolutely
> must be fixed before it can become the default
I'd agree, though I'd have a different list of pet bugs.
But that's a subjective judgement. I'd be the first to admit that I'm
pretty risk averse, especially when it comes to losing data and
rendering machines unbootable.
I think both of us are making a subjective judgement. For myself, I
"want to believe" in btrfs, having championed immutable
state/wandering trees, and real databases for many years.
BUT I'm deeply unhappy about data corrupting bugs being effectively
ignored by upstream for months. That's not good.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
2:36 p.m.
On Wed, Jan 16, 2013 at 1:50 PM, Richard W.M. Jones <rjones(a)redhat.com>wrote:
On Wed, Jan 16, 2013 at 10:12:34AM -0800, Zach Brown wrote:
> > So there are a couple of issues with btrfs which I believe absolutely
> > must be fixed before it can become the default
>
> I'd agree, though I'd have a different list of pet bugs.
>
> But that's a subjective judgement. I'd be the first to admit that I'm
> pretty risk averse, especially when it comes to losing data and
> rendering machines unbootable.
I think both of us are making a subjective judgement. For myself, I
"want to believe" in btrfs, having championed immutable
state/wandering trees, and real databases for many years.
BUT I'm deeply unhappy about data corrupting bugs being effectively
ignored by upstream for months. That's not good.
I see no data corruption bugs that have been reported that are being
ignored, link to the email? The invalidate stuff was causing problems (not
a btrfs problem, we just got hurt by it the most), and it looks like those
were cleared up. I'm working on the only data corruption problem I know of
at the moment and it's not super clear its a data corruption problem.
Thanks,
Josef
3:11 p.m.
On Wed, Jan 16, 2013 at 03:36:10PM -0500, Josef Bacik wrote:
On Wed, Jan 16, 2013 at 1:50 PM, Richard W.M. Jones
<rjones(a)redhat.com>wrote:
> On Wed, Jan 16, 2013 at 10:12:34AM -0800, Zach Brown wrote:
> > > So there are a couple of issues with btrfs which I believe absolutely
> > > must be fixed before it can become the default
> >
> > I'd agree, though I'd have a different list of pet bugs.
> >
> > But that's a subjective judgement. I'd be the first to admit that
I'm
> > pretty risk averse, especially when it comes to losing data and
> > rendering machines unbootable.
>
> I think both of us are making a subjective judgement. For myself, I
> "want to believe" in btrfs, having championed immutable
> state/wandering trees, and real databases for many years.
>
> BUT I'm deeply unhappy about data corrupting bugs being effectively
> ignored by upstream for months. That's not good.
>
>
I see no data corruption bugs that have been reported that are being
ignored, link to the email? The invalidate stuff was causing problems (not
a btrfs problem, we just got hurt by it the most), and it looks like those
were cleared up. I'm working on the only data corruption problem I know of
at the moment and it's not super clear its a data corruption problem.
The link is:
https://bugzilla.redhat.com/show_bug.cgi?id=863978
Reported upstream here:
http://thread.gmane.org/gmane.comp.file-systems.btrfs/20257
I'd love this to have been fixed upstream somewhere. It is still
affecting Fedora, but we can pull in the fix if you can point to it.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
3:15 p.m.
On Wed, Jan 16, 2013 at 9:11 PM, Richard W.M. Jones <rjones(a)redhat.com>wrote:
On Wed, Jan 16, 2013 at 03:36:10PM -0500, Josef Bacik wrote:
> On Wed, Jan 16, 2013 at 1:50 PM, Richard W.M. Jones <rjones(a)redhat.com
>wrote:
>
> > On Wed, Jan 16, 2013 at 10:12:34AM -0800, Zach Brown wrote:
> > > > So there are a couple of issues with btrfs which I believe
absolutely
> > > > must be fixed before it can become the default
> > >
> > > I'd agree, though I'd have a different list of pet bugs.
> > >
> > > But that's a subjective judgement. I'd be the first to admit
that
I'm
> > > pretty risk averse, especially when it comes to losing data and
> > > rendering machines unbootable.
> >
> > I think both of us are making a subjective judgement. For myself, I
> > "want to believe" in btrfs, having championed immutable
> > state/wandering trees, and real databases for many years.
> >
> > BUT I'm deeply unhappy about data corrupting bugs being effectively
> > ignored by upstream for months. That's not good.
> >
> >
> I see no data corruption bugs that have been reported that are being
> ignored, link to the email? The invalidate stuff was causing problems
(not
> a btrfs problem, we just got hurt by it the most), and it looks like
those
> were cleared up. I'm working on the only data corruption problem I know
of
> at the moment and it's not super clear its a data corruption problem.
The link is:
https://bugzilla.redhat.com/show_bug.cgi?id=863978
Reported upstream here:
http://thread.gmane.org/gmane.comp.file-systems.btrfs/20257
I'd love this to have been fixed upstream somewhere. It is still
affecting Fedora, but we can pull in the fix if you can point to it.
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com
Fedora now supports 80 OCaml packages (the OPEN alternative to F#)
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Maybe is not good idea. Wait when btrfs launch officialy a least 1 stable
version, because nothing 1 release yet.
--
Álvaro Castillo
Fedora Project, EMEA ambassador
http://fedoraproject.org/wiki/User:Netsys
Linux user #547784
4:07 p.m.
On Wed, Jan 16, 2013 at 12:18 PM, Richard W.M. Jones <rjones(a)redhat.com> wrote:
On Wed, Jan 16, 2013 at 09:53:25AM +0100, Jochen Schmitt wrote:
> Hallo,
>
> for Fedora 17 we had a feature to make btrfs to the
> standard filesystem of Fedora. This feature was defered
> because the fsck utitlities for btrfs was not available
> on the stable state for Fedora 17.
>
> So, I would like to ask, if there any plans to make this to
> a feautre for F-19. I think it may be sense to integreate
> this feature to the rewrite of the part of anaconde which
> is responsible for disc partitioning. In a article of the
> c't magazin (a german computer magazin) I could read, that
> this part of the new release of anaconda may be get any
> more love.
>
> Additionally, because I have read about an issue relating
> btrfs with LVM2 on this mailing list and lost the thread, I
> woould like to ask about the starte of this issue.
So there are a couple of issues with btrfs which I believe absolutely
must be fixed before it can become the default (both affect
virtualization, coincidentally):
I thought one of the biggest blockers was the lack of a complete and
stable fsck implementation for it.
Peter
5:23 p.m.
To make BTRFS (or any new file-system) the default for a distribution
will be really hard.
My thought on the subject:
-1. IS IT STILL DESIRED TO MAKE BTRFS THE DEFAULT FILE-SYSTEM FOR
FEDORA AT SOME (yet unknown) POINT IN THE FUTURE?
0. DETERMINE A ROOT FILE-SYSTEM CRITERIA (AND/OR a DEFAULT FS CRITERIA)
* Does it exists somewhere in written and consolidated form?
1. DETERMINE CURRENT BTRFS STATUS (F18 ONWARDS)
* See below.
2. EVALUATE IF 'CURRENT BTRFS STATUS' MEETS 'ROOT|DEFAULT FILE-SYSTEM
CRITERIA'
3. ANACONDA: DETERMINE WHICH BTRFS FEATURES WILL BE SUPPORTED
* Which raid levels, data, metadata, subvol, etc. Maybe some
features will not be available or supported (either by a bug or by
design).
4. ANACONDA: DETERMINE WHICH BTRFS DEFAULTS WILL USED
* DEFAULTS FOR AUTOMATIC PARTITIONING with SCHEME as BTRFS
* DEFAULTS FOR MANUAL PARTITIONING with SCHEME as BTRFS
> currently (and correct me if i am wrong): STANDARD PARTITIONS:
for SWAP and /boot, / as btrfs
5. ANACONDA: HANDLE ALL BTRFS SIZE/FREE SPACE REQUIREMENTS
* To be able to REJECT all Storage Configurations in which the
resulting btrfs file-system will be too small and either fail or hit a
known-bug/issue (which was declared non-blocker).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. DETERMINE CURRENT BTRFS STATUS (F18 ONWARDS)
A page similar to
http://qa.fedoraproject.org/blockerbugs/milestone/18/final/buglist
could be created to track 'BTRFS AS DEFAULT FS' status. Anybody
interested in BTRFS
as the default file-system for Fedora will be able to see at a glance
how is that
going. Bug-reports will be still filled against bugzilla.
Tackers:
* BTRFS_INSTALLER_SUPPORT
Criteria TBD... (need input from Anaconda developers)
DRAF: Any bug/issue that impacts the installer.
* FS_RELIABILITY
Criteria TBD...
DRAFT: Any bug in which the file-system behaves erratically or incorrectly.
Data Loss and Data Corruption are the worst example.
* FS_PERFORMANCE
Criteria TBD... (but as the name implies)
DRAFT: Any bug that is NOT in FS_RELIABILITY in which the
file-system is performing 'correctly' but its performance is not ok.
* FS_MISC_ISSUES
Criteria TBD...
DRAFT: Any bug that is NOT in either FS_RELIABILITY nor
FS_PERFORMANCE. Also it must not be on BTRFS_INSTALLER_SUPPORT.
* BTRFS_ISSUES_QUEUE
DRAFT: Anybody could mark any btrfs bug as blocking this. Then some
assigned people can classify this queue and put them into any of the
previous queues.
* BTRFS_FEATURE_MAP
DRAFT: A link to another page in which all btrfs features and
possible configurations are rated: UNK | OK | ISSUE:MISC | ISSUE:PERF
| ISSUE:REL | ISSUE:INST
Example: BTRFS vXX MIRROR on VIRTIO: ISSUE:REL (very drafty)
The idea of this is that one could see at a glance, which subset of
features are the most problematic ones, and more.
Something similar to: http://www.x.org/wiki/RadeonFeature
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
I know that it is a bit overkill, but maybe some subset of this could be done.
Cheers.
11:14 p.m.
On Jan 16, 2013, at 3:07 PM, Peter Robinson <pbrobinson(a)gmail.com> wrote:
I thought one of the biggest blockers was the lack of a complete and
stable fsck implementation for it.
I think this is a poor metric for outsiders to require. ZFS has been stable for some time
and does not have an fsck. A more important question from those not directly involved in
Btrfs development, is when is it stable enough that developers will be willing to back
port significant fixes to older kernels. Currently the #1 suggestion on linux-btrfs@ when
users have problems is to try the latest kernel, i.e. a week ago the suggestion to a user
was to try it on 3.8.0.-rc3, which currently only appeared about 5 days ago for rawhide.
Not F18.
So if regular Fedora users having Btrfs problems are going to be told to use kernels that
might not even available in koji, let alone not in updates-testing for the actual current
released version? I think that's disqualifying. Not the lack of a stable or complete
fsck.
On Jan 16, 2013, at 2:49 PM, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Thu, 17 Jan 2013 08:13:07 +1030
William Brown <william(a)firstyear.id.au> wrote:
> I take it then that subvolid 258 is marked as "/" in your fstab?
yes, via a subvol=root fstab entry.
Has anyone tested subvolid=xxx works for rootfs yet? I know GRUB 2 will not resolve
subvolid, it essentially treats subvols as folders, but does it only with pathnames, not
ID number. If fstab uses subvolid for boot, then boot fails. I'm not sure if systemd
and dracut will handle rootfs defined by subvolid. This is more stable, as the subvolume
can be renamed or moved, and things still work. Whereas with subvol (name) things can
break.
Chris Murphy
2:20 a.m.
On Wed, Jan 16, 2013 at 10:14:32PM -0700, Chris Murphy wrote:
Has anyone tested subvolid=xxx works for rootfs yet? I know GRUB 2
will not resolve subvolid, it essentially treats subvols as folders,
but does it only with pathnames, not ID number. If fstab uses
subvolid for boot, then boot fails. I'm not sure if systemd and
dracut will handle rootfs defined by subvolid. This is more stable,
as the subvolume can be renamed or moved, and things still
work. Whereas with subvol (name) things can break.
Breaks libguestfs inspection too, although we have a fairly solid plan
(not implemented yet) to support it.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
5:10 p.m.
On Wednesday 16 January 2013 12:18:19 Richard W.M. Jones wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=689127
(performance problem with virtual machines)
I must add that, in my experience, the performance is *bad* not only in virtual machines
but in the whole user experience (I've been using btrfs in my /home partition for a
while now and I'm sorry to say that it's really slow compared to ext4).
In my humble opinion, as of right now, btrfs is not yet ready to be used as default
Regards,
Marc
6 p.m.
On Thu, Jan 17, 2013 at 3:10 PM, Marc Deop Argemí <marc(a)marcdeop.com> wrote:
On Wednesday 16 January 2013 12:18:19 Richard W.M. Jones wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=689127
> (performance problem with virtual machines)
I must add that, in my experience, the performance is *bad* not only in virtual machines
but in the whole user experience (I've been using btrfs in my /home partition for a
while now and I'm sorry to say that it's really slow compared to ext4).
In my humble opinion, as of right now, btrfs is not yet ready to be used as default
Regards,
Marc
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Yes, I'd veto btrfs as the default as well. I lost a huge chunk of
data on a btrfs partition a while back, with *no* diagnostics,
recovery tools, help from Google, etc. Screw speed - unless it's rock
solid and *simple* to back up, maintain, diagnose and manage, I won't
use it.
--
Twitter: http://twitter.com/znmeb; Computational Journalism Publishers
Workbench: http://znmeb.github.com/Computational-Journalism-Publishers-Workbench/
How the Hell can the lion sleep with all those people singing "A weem
oh way!" at the top of their lungs?
7:19 p.m.
On 01/17/2013 07:00 PM, M. Edward (Ed) Borasky wrote:
Yes, I'd veto btrfs as the default as well. I lost a huge chunk
of
data on a btrfs partition a while back, with *no* diagnostics,
recovery tools, help from Google, etc. Screw speed - unless it's rock
solid and *simple* to back up, maintain, diagnose and manage, I won't
use it.
You don't have the power to veto it although highlighting critical bugs
will be beneficial. If you are going to highlight them, do post
bugzilla links rather than descriptions of the issues.
Rahul
9:50 a.m.
On 18 January 2013 01:19, Rahul Sundaram <metherid(a)gmail.com> wrote:
On 01/17/2013 07:00 PM, M. Edward (Ed) Borasky wrote:
>
> Yes, I'd veto btrfs as the default as well. I lost a huge chunk of
> data on a btrfs partition a while back, with *no* diagnostics,
> recovery tools, help from Google, etc. Screw speed - unless it's rock
> solid and *simple* to back up, maintain, diagnose and manage, I won't
> use it.
You don't have the power to veto it although highlighting critical bugs will
be beneficial. If you are going to highlight them, do post bugzilla links
rather than descriptions of the issues.
I suggest sdfs as the new default filesystem, you cannot veto it, but
highlighting critical bugs will be beneficial. Please post bugzilla
links rather than descriptions of the issues.
Or:
Bugs are not a replacement for discussion.
--
imalone
http://ibmalone.blogspot.co.uk
11:19 a.m.
On 01/18/2013 10:50 AM, Ian Malone wrote:
I suggest sdfs as the new default filesystem, you cannot veto it, but
highlighting critical bugs will be beneficial. Please post bugzilla
links rather than descriptions of the issues. Or: Bugs are not a
replacement for discussion.
A discussion by definition cannot include a veto but bugs are a useful
data point for these discussions.
Rahul
4:26 p.m.
On 18 January 2013 17:19, Rahul Sundaram <metherid(a)gmail.com> wrote:
On 01/18/2013 10:50 AM, Ian Malone wrote:
>
> I suggest sdfs as the new default filesystem, you cannot veto it, but
> highlighting critical bugs will be beneficial. Please post bugzilla links
> rather than descriptions of the issues. Or: Bugs are not a replacement for
> discussion.
A discussion by definition cannot include a veto but bugs are a useful data
point for these discussions.
What you wrote:
If you are going to highlight them, do post bugzilla links
rather than descriptions of the issues.
Or in other words, don't bring up anything here unless it's not in
bugzilla, if it's not in bugzilla go and put it there before we'll
discuss it.
The thing is, Fedora 16 has just gone EOL and I'm getting back the
emails for the bugs I filled that are being closed because of this.
Quite a few of them. And it takes time to create a proper bug report,
then you get told to take it upstream anyway. To say you must go
through that before raising issues in a discussion about how ready a
filesystem is to be made the default in the next fedora release (a
fairly major change) does seem to be setting the bar a little high.
You were replying to someone's opinion ("I'd veto it," not the same
as, "I veto it") and experience (data loss under btrfs, though of
course more details would be helpful).
I'm sure you'll reply explaining exactly how you did not say that, but
I don't expect everyone who gets bitten by a major filesystem bug
actually files one, they're likely to just change to something that
works.
--
imalone
http://ibmalone.blogspot.co.uk
4:57 p.m.
Hi
On Fri, Jan 18, 2013 at 5:26 PM, Ian Malone wrote:
Or in other words, don't bring up anything here unless it's
not in
bugzilla, if it's not in bugzilla go and put it there before we'll
discuss it.
I wouldn't read it that rigidly. Its more along the lines of, its more
helpful to file bug reports and post them for discussions because its
easier to keep track of. Even when they dont get fixed, it will serve as
documentation for the relevant issues.
Rahul
3:25 a.m.
On Fri, 18 Jan 2013 23:57:38 +0100, Rahul Sundaram wrote:
I wouldn't read it that rigidly. Its more along the lines of,
its more
helpful to file bug reports and post them for discussions because its
easier to keep track of.
I have already filed enough stopper Bugs for btrfs and nothing happened with
them. After a year of pain I had to finally switch back as I also have to
work on that machine. So the Bugs part has been done, it did not help.
http://lists.fedoraproject.org/pipermail/devel/2013-January/176334.html
I am aware the best way to fix known Bugs is ... to just fix those Bugs.
Jan
6:16 a.m.
On 01/19/2013 10:25 AM, Jan Kratochvil wrote:
I am aware the best way to fix known Bugs is ... to just fix those
Bugs.
Maybe I am pronouncing the obvious, but I am wondering, whether you guys
have a "required feature" list and a regression test-suite?
At least to me, having both and complying to both would be a necessary
requirement before making with the importance as file system "default".
Ralf
9:55 a.m.
On 01/17/2013 08:19 PM, Rahul Sundaram wrote:
On 01/17/2013 07:00 PM, M. Edward (Ed) Borasky wrote:
> Yes, I'd veto btrfs as the default as well. I lost a huge chunk of
> data on a btrfs partition a while back, with *no* diagnostics,
..
You don't have the power to veto it although highlighting
critical bugs
will be beneficial. If you are going to highlight them, do post
bugzilla links rather than descriptions of the issues.
I used btrfs on my personal desktop for about a year now and it works
fine for me, other than a nagging suspicion that there's an occasional
performance problem at high load. I can't say anything intelligent about
it because I coudn't figure out how to measure what I feel, but the
system seems sluggish during high-impact events like 'yum update' and/or
firefox with gazillion tabs open. The simple diagnostics (top, ps,
iotop) don't seem to point to anything definitive: it essentially shows
reasonable CPU load, relatively low IO rate and load average in single
digits, with occasional significant (second-like) latency for simple
things like window exposes and terminal keystrokes.
I tried to come up with ways of measuring and quantifying, e.g. with
systemtap, but it didn't get me anywhere. It would be great if someone
familiar with performance measurements could write up how to narrow down
issues like that in a complex desktop situation where X interacts with
IO, networking, virtual memory, etc.
Even better, maybe there's a way to have a kernel-side or Xserver-side
component that automatically detects user interaction latency and logs
warnings that would help in pinpointing the causes. I assume that
latency can be detected by comparing low-level event times (USB traffic
from the mouse, etc), to high-level event times like window redraws.
9:21 a.m.
On Friday, January 18, 2013 10:55:23 Przemek Klosowski wrote:
I used btrfs on my personal desktop for about a year now and it
works fine for me, other than a nagging suspicion that there's an
occasional performance problem at high load.
Yes, this is familiar. I too have used it for over a year. I am only
using it for /home since the file fragmentation problem was unbearable
in /var running yum. The performance problems I experience now are
probably related to this:
https://btrfs.wiki.kernel.org/index.php/Gotchas (first issue)
The last time I tried mounting with autodefrag, it was not much
improved and I worried that my kernel was not new enough to run that
mount option. Now that I just upgraded to F18, I will try again.
The bottom line from my personal experience is if the autodefrag
option works well in /home, I would say I'm ready to see btrfs as the
default. Otherwise, it would probably be a problem on workstations
and certain server environments.
Aside from performance, it has been flawless for me over the last year
or so.
I can't say anything intelligent about it because I coudn't
figure
out how to measure what I feel, but the system seems sluggish during
high-impact events like 'yum update' and/or firefox with gazillion
tabs open.
This duplicates my experience. I don't have anything intelligent to
say about it either. :-)
--
Garry T. Williams
9:12 a.m.
On 01/18/2013 01:00 AM, M. Edward (Ed) Borasky wrote:
On Thu, Jan 17, 2013 at 3:10 PM, Marc Deop Argemí
<marc(a)marcdeop.com> wrote:
> On Wednesday 16 January 2013 12:18:19 Richard W.M. Jones wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=689127
>> (performance problem with virtual machines)
>
> I must add that, in my experience, the performance is *bad* not only in virtual
machines but in the whole user experience (I've been using btrfs in my /home partition
for a while now and I'm sorry to say that it's really slow compared to ext4).
>
> In my humble opinion, as of right now, btrfs is not yet ready to be used as default
>
> Regards,
>
> Marc
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
Yes, I'd veto btrfs as the default as well. I lost a huge chunk of
data on a btrfs partition a while back, with *no* diagnostics,
recovery tools, help from Google, etc. Screw speed - unless it's rock
solid and *simple* to back up, maintain, diagnose and manage, I won't
use it.
The most helpful approach would be provide bug reports, when btrfs will
be proposed as a default file system (again). Without bug reports, real
numbers etc. is hard to make any decision. I don't wish to test on my
machine, so I would be glad for hard data from others ;-)
(btw the typo in subject is terrible).
Marcela
1:14 p.m.
On 18/01/13 16:12, Marcela Mašláňová wrote:
The most helpful approach would be provide bug reports, when btrfs
will
be proposed as a default file system (again). Without bug reports, real
numbers etc. is hard to make any decision. I don't wish to test on my
machine, so I would be glad for hard data from others ;-)
This is not enough
https://bugzilla.redhat.com/buglist.cgi?quicksearch=component%3Akernel%20...
?
Matěj
11:18 a.m.
On Wed, Jan 16, 2013 at 3:53 AM, Jochen Schmitt <Jochen(a)herr-schmitt.de>wrote:
Hallo,
for Fedora 17 we had a feature to make btrfs to the
standard filesystem of Fedora. This feature was defered
because the fsck utitlities for btrfs was not available
on the stable state for Fedora 17.
So, I would like to ask, if there any plans to make this to
a feautre for F-19. I think it may be sense to integreate
this feature to the rewrite of the part of anaconde which
is responsible for disc partitioning. In a article of the
c't magazin (a german computer magazin) I could read, that
this part of the new release of anaconda may be get any
more love.
Additionally, because I have read about an issue relating
btrfs with LVM2 on this mailing list and lost the thread, I
woould like to ask about the starte of this issue.
I'm waiting until Anaconda settles down before I pursue btrfs in Fedora
again. Things change too much and Btrfs is too reliant on the anaconda
part working properly to even bother trying to push it through at this
point. Thanks,
Josef
2:17 p.m.
On Wed, 16 Jan 2013 12:18:37 -0500
Josef Bacik <josef(a)toxicpanda.com> wrote:
I'm waiting until Anaconda settles down before I pursue btrfs in
Fedora again. Things change too much and Btrfs is too reliant on the
anaconda part working properly to even bother trying to push it
through at this point. Thanks,
Well, I hope we are entering a period of bugfixing and incremental
improvement in anaconda since we have the new code in now. ;)
FWIW, I installed with btrfs with the f18 installer and it worked fine.
(encrypted volume with / and /home subvolumes). I kept /boot as ext4
due to a anaconda issue, which I think has already been fixed.
So, you might want to talk to anaconda folks and get their feedback...
kevin
3:16 p.m.
On Wed, 2013-01-16 at 13:17 -0700, Kevin Fenzi wrote:
On Wed, 16 Jan 2013 12:18:37 -0500
Josef Bacik <josef(a)toxicpanda.com> wrote:
> I'm waiting until Anaconda settles down before I pursue btrfs in
> Fedora again. Things change too much and Btrfs is too reliant on the
> anaconda part working properly to even bother trying to push it
> through at this point. Thanks,
Well, I hope we are entering a period of bugfixing and incremental
improvement in anaconda since we have the new code in now. ;)
FWIW, I installed with btrfs with the f18 installer and it worked fine.
(encrypted volume with / and /home subvolumes). I kept /boot as ext4
due to a anaconda issue, which I think has already been fixed.
So, you might want to talk to anaconda folks and get their feedback...
kevin
Did the root volume (/) Go into it's own subvolume, or is root just
in /?
If root isn't placed into a subvolume, say /root then mounted
as /dev/sda1 subvolid=255 / lets say, you can't snapshot the root fs,
which defeats the whole point of using btrfs .....
--
Sincerely,
William Brown
pgp.mit.edu
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x3C0AC6DAB2F928A2
3:20 p.m.
On Thu, 17 Jan 2013 07:46:34 +1030
William Brown <william(a)firstyear.id.au> wrote:
Did the root volume (/) Go into it's own subvolume, or is root
just
in /?
If root isn't placed into a subvolume, say /root then mounted
as /dev/sda1 subvolid=255 / lets say, you can't snapshot the root fs,
which defeats the whole point of using btrfs .....
# btrfs subvolume list -a /
ID 256 gen 56580 top level 5 path <FS_TREE>/home
ID 258 gen 56580 top level 5 path <FS_TREE>/root
ID 1226 gen 55781 top level 258 path .snapshots/2013-01-16--07-00-02-@hourly
ID 1227 gen 55781 top level 5 path
<FS_TREE>/home/.snapshots/2013-01-16--07-00-02-@hourly
ID 1229 gen 55890 top level 5 path
<FS_TREE>/home/.snapshots/2013-01-16--08-00-01-@hourly
ID 1230 gen 55891 top level 258 path .snapshots/2013-01-16--08-00-01-@hourly
ID 1232 gen 55999 top level 258 path .snapshots/2013-01-16--09-00-02-@hourly
ID 1233 gen 55999 top level 5 path
<FS_TREE>/home/.snapshots/2013-01-16--09-00-02-@hourly
ID 1234 gen 56109 top level 5 path
<FS_TREE>/home/.snapshots/2013-01-16--10-00-01-@hourly
ID 1235 gen 56109 top level 258 path .snapshots/2013-01-16--10-00-01-@hourly
ID 1236 gen 56220 top level 5 path
<FS_TREE>/home/.snapshots/2013-01-16--11-00-01-@hourly
ID 1237 gen 56220 top level 258 path .snapshots/2013-01-16--11-00-01-@hourly
ID 1238 gen 56327 top level 258 path .snapshots/2013-01-16--12-00-01-@hourly
ID 1239 gen 56327 top level 5 path
<FS_TREE>/home/.snapshots/2013-01-16--12-00-01-@hourly
ID 1240 gen 56438 top level 258 path .snapshots/2013-01-16--13-00-01-@hourly
ID 1241 gen 56438 top level 5 path
<FS_TREE>/home/.snapshots/2013-01-16--13-00-01-@hourly
ID 1242 gen 56549 top level 5 path
<FS_TREE>/home/.snapshots/2013-01-16--14-00-01-@hourly
ID 1243 gen 56549 top level 258 path .snapshots/2013-01-16--14-00-01-@hourly
...
kevin
3:43 p.m.
ID 258 gen 56580 top level 5 path <FS_TREE>/root
I take it then that subvolid 258 is marked as "/" in your fstab?
--
Sincerely,
William Brown
pgp.mit.edu
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x3C0AC6DAB2F928A2
3:26 p.m.
On Thu, 2013-01-17 at 07:46 +1030, William Brown wrote:
On Wed, 2013-01-16 at 13:17 -0700, Kevin Fenzi wrote:
> On Wed, 16 Jan 2013 12:18:37 -0500
> Josef Bacik <josef(a)toxicpanda.com> wrote:
>
> > I'm waiting until Anaconda settles down before I pursue btrfs in
> > Fedora again. Things change too much and Btrfs is too reliant on the
> > anaconda part working properly to even bother trying to push it
> > through at this point. Thanks,
>
> Well, I hope we are entering a period of bugfixing and incremental
> improvement in anaconda since we have the new code in now. ;)
>
> FWIW, I installed with btrfs with the f18 installer and it worked fine.
> (encrypted volume with / and /home subvolumes). I kept /boot as ext4
> due to a anaconda issue, which I think has already been fixed.
>
> So, you might want to talk to anaconda folks and get their feedback...
>
> kevin
Did the root volume (/) Go into it's own subvolume, or is root just
in /?
If root isn't placed into a subvolume, say /root then mounted
as /dev/sda1 subvolid=255 / lets say, you can't snapshot the root fs,
which defeats the whole point of using btrfs .....
In F18 every btrfs mountpoint you create gets a subvolume unless you use
kickstart custom partitioning and don't use subvols.
3:28 p.m.
On 01/16/2013 01:16 PM, William Brown wrote:
If root isn't placed into a subvolume, say /root then mounted
as /dev/sda1 subvolid=255 / lets say, you can't snapshot the root fs,
which defeats the whole point of using btrfs .....
Yes you can -- the btrfs wiki even has this example:
mount -t btrfs /dev/sda2 /mnt/btrfs
btrfs subvolume create /mnt/btrfs/new_subvol
btrfs subvolume snapshot /mnt/btrfs /mnt/btrfs/snapshot_of_root
Here the snapshot lives within the subvolume being captured. This
should work just fine when mounted at / too.
10:01 a.m.
On 01/16/2013 12:18 PM, Josef Bacik wrote:
On Wed, Jan 16, 2013 at 3:53 AM, Jochen Schmitt
<Jochen(a)herr-schmitt.de <mailto:Jochen@herr-schmitt.de>> wrote:
Hallo,
for Fedora 17 we had a feature to make btrfs to the
standard filesystem of Fedora. This feature was defered
because the fsck utitlities for btrfs was not available
on the stable state for Fedora 17.
So, I would like to ask, if there any plans to make this to
a feautre for F-19. I think it may be sense to integreate
this feature to the rewrite of the part of anaconde which
is responsible for disc partitioning. In a article of the
c't magazin (a german computer magazin) I could read, that
this part of the new release of anaconda may be get any
more love.
Additionally, because I have read about an issue relating
btrfs with LVM2 on this mailing list and lost the thread, I
woould like to ask about the starte of this issue.
I'm waiting until Anaconda settles down before I pursue btrfs in
Fedora again. Things change too much and Btrfs is too reliant on the
anaconda part working properly to even bother trying to push it
through at this point. Thanks,
In flurry of activity in the last days before Fedora 18 was final, there
were a number of fixes made to anaconda to accommodate btrfs including
being able to put root, boot, or root+boot and an btrfs subvolume as
well as support for multi-device btrfs filesystems. While I am sure
there is more to do, is is usable.
However, while I have a great interest in btrfs because of its
potential, I do not believe that it is ready to be the default
filesystem yet.
A bug which has not been filed in bugzilla is not a bug. A bug report
in Fedora/RedHat bugzilla, which has not been reported upstream, is not
a bug as far as the btrfs developers are concerned because they are not
aware of its existence.
Gene
2:08 p.m.
On Wed, 2013-01-16 at 09:53 +0100, Jochen Schmitt wrote:
Hallo,
for Fedora 17 we had a feature to make btrfs to the
standard filesystem of Fedora. This feature was defered
because the fsck utitlities for btrfs was not available
on the stable state for Fedora 17.
So, I would like to ask, if there any plans to make this to
a feautre for F-19. I think it may be sense to integreate
this feature to the rewrite of the part of anaconde which
is responsible for disc partitioning. In a article of the
c't magazin (a german computer magazin) I could read, that
this part of the new release of anaconda may be get any
more love.
Additionally, because I have read about an issue relating
btrfs with LVM2 on this mailing list and lost the thread, I
woould like to ask about the starte of this issue.
There's been some useful and interesting discussion in this thread about
the kernel and anaconda layers, but I think the higher layers also need
to be taken into account. I only really started poking at btrfs at all
seriously during F18 testing, and what I noticed that I hadn't really
understood before is that some user-level tools just don't work well
with btrfs at all.
btrfs gives you a whole suite of its own command line tools, in
'btrfs-progs', which you're supposed to use to inspect and fiddle with
btrfs volumes and subvols. Which, I mean, great, I guess. But what
worries me is that tools that sysadmins use on a daily basis, like 'df'
and 'mount', just don't really work with btrfs at all. They show you
something that at some deeply technical level is correct, but is not the
info you were really expecting - 'what's mounted where?' and 'how much
space do I have left on XXX?'.
I understand that btrfs is a Different Way Of Doing Things, but I don't
think it flies to tell people 'yeah, the tools you've relied on for
simple info on filesystems for years don't work any more, learn this
whole new set of tools'. There should at least be an effort to make very
standard tools return information that's as close as possible to what
the user wanted. This is particularly important in the context of 'make
it the default': right now we can make a reasonable assumption that
people who pick to install with btrfs are actively interested in it and
willing to learn the Right Way to interact with it, but by making it the
default, we'd be
df and mount are the two that stick out most clearly in my memory, but
I'm sure there are others and people may be able to contribute them.
gnome-disks also doesn't really interpret btrfs right at all, or didn't
the last time I checked.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:53 p.m.
On Wed, 2013-01-23 at 12:08 -0800, Adam Williamson wrote:
Mistakenly left this paragraph incomplete, completion follows:
I understand that btrfs is a Different Way Of Doing Things, but I
don't
think it flies to tell people 'yeah, the tools you've relied on for
simple info on filesystems for years don't work any more, learn this
whole new set of tools'. There should at least be an effort to make very
standard tools return information that's as close as possible to what
the user wanted. This is particularly important in the context of 'make
it the default': right now we can make a reasonable assumption that
people who pick to install with btrfs are actively interested in it and
willing to learn the Right Way to interact with it, but by making it the
default, we'd be
...causing people who aren't particularly interested in btrfs to use it,
people who probably would be unhappy if the standard tools they'd been
using for years or decades suddenly started reporting what is
effectively nonsense.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
9:23 a.m.
On 01/23/2013 03:53 PM, Adam Williamson wrote:
On Wed, 2013-01-23 at 12:08 -0800, Adam Williamson wrote:
Mistakenly left this paragraph incomplete, completion follows:
> I understand that btrfs is a Different Way Of Doing Things, but I don't
> think it flies to tell people 'yeah, the tools you've relied on for
> simple info on filesystems for years don't work any more, learn this
> whole new set of tools'. There should at least be an effort to make very
> standard tools return information that's as close as possible to what
> the user wanted. This is particularly important in the context of 'make
> it the default': right now we can make a reasonable assumption that
> people who pick to install with btrfs are actively interested in it and
> willing to learn the Right Way to interact with it, but by making it the
> default, we'd be
...causing people who aren't particularly interested in btrfs to use it,
people who probably would be unhappy if the standard tools they'd been
using for years or decades suddenly started reporting what is
effectively nonsense.
Some of the issues with space reporting are really the same challenges we have
with traditional file systems when we have active read-write snapshots under
them. Space accounting gets tricky when things like "rm" can actually increase
the utilized blocks in your storage pool :)
Not sure that there is an easy path forward here and this will clearly take some
time for people to wrap their heads around,
Ric
9:36 a.m.
http://article.gmane.org/gmane.comp.file-systems.btrfs/22555
(Quota reached: can't delete)
When you reach a quota limit, the first intuitive action one takes is
to delete something to make space.
But aparently (and currently) with btrfs one needs to change the quota
and then delete.
I have not yet tested this, but i will test it later.
Free space in btrfs is really different.
Some of the issues with space reporting are really the same
challenges we
have with traditional file systems when we have active read-write snapshots
under them. Space accounting gets tricky when things like "rm" can actually
increase the utilized blocks in your storage pool :)
Not sure that there is an easy path forward here and this will clearly take
some time for people to wrap their heads around,
Ric
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
6:44 p.m.
On Thu, 2013-01-24 at 12:36 -0300, Reartes Guillermo wrote:
http://article.gmane.org/gmane.comp.file-systems.btrfs/22555
(Quota reached: can't delete)
When you reach a quota limit, the first intuitive action one takes is
to delete something to make space.
But aparently (and currently) with btrfs one needs to change the quota
and then delete.
I have not yet tested this, but i will test it later.
Free space in btrfs is really different.
Just about everything in btrfs is really different :) I'm still wrapping
my head around it too. But as far as possible, the 'legacy' tools should
show something as accurate and useful as they can, I believe.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
8:56 p.m.
On Jan 24, 2013, at 5:44 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
Just about everything in btrfs is really different :) I'm still wrapping
my head around it too. But as far as possible, the 'legacy' tools should
show something as accurate and useful as they can, I believe.
For mount, the only issue I know of is that it doesn't show subvolume mounted. Ubuntu
reportedly does (I don't use it so I can't confirm/deny), even though it's
using older btrfs-progs, and older linux-utils. So I'm not sure why Fedora doesn't
show subvolumes in mount. I have to do cat /proc/self/mountinfo to get this information on
Fedora.
For df, it's maybe more challenging. The use cases where it's a problem: small
devices, e.g. less than 100GB and also not formatted with the mixed data/metadata option;
and pushing the usage of a device of any size to nearly it's full capacity (beyond
90%). But even a scale algorithm that changes the Capacity % bias from predominantly data,
to predominantly metadata doesn't fix the problem.
e.g. 95% Capacity per df, with a heavy metadata usage of the file system. Further metadata
heavy writes might mean you're actually at 99% Capacity, whereas with minimal metadata
writes might mean you're at 92% capacity. So which is correct to report? It depends on
future usage, which is unknown. Small problem.
Chris Murphy
9:27 p.m.
On Thu, 2013-01-24 at 19:56 -0700, Chris Murphy wrote:
On Jan 24, 2013, at 5:44 PM, Adam Williamson
<awilliam(a)redhat.com>
wrote:
>
> Just about everything in btrfs is really different :) I'm still
wrapping
> my head around it too. But as far as possible, the 'legacy' tools
should
> show something as accurate and useful as they can, I believe.
For mount, the only issue I know of is that it doesn't show subvolume
mounted. Ubuntu reportedly does (I don't use it so I can't
confirm/deny), even though it's using older btrfs-progs, and older
linux-utils. So I'm not sure why Fedora doesn't show subvolumes in
mount. I have to do cat /proc/self/mountinfo to get this information
on Fedora.
For df, it's maybe more challenging. The use cases where it's a
problem: small devices, e.g. less than 100GB and also not formatted
with the mixed data/metadata option; and pushing the usage of a device
of any size to nearly it's full capacity (beyond 90%). But even a
scale algorithm that changes the Capacity % bias from predominantly
data, to predominantly metadata doesn't fix the problem.
e.g. 95% Capacity per df, with a heavy metadata usage of the file
system. Further metadata heavy writes might mean you're actually at
99% Capacity, whereas with minimal metadata writes might mean you're
at 92% capacity. So which is correct to report? It depends on future
usage, which is unknown. Small problem.
Well that's not the one I was thinking of, actually - I believe I was
hit by cases where some subvols use redundancy, in which case df goes
completely wrong. I'd have to re-install and re-check to be sure of
exactly what I saw go wrong, though.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
10:30 p.m.
On Jan 24, 2013, at 8:27 PM, Adam Williamson <awilliam(a)redhat.com> wrote:
>
Well that's not the one I was thinking of, actually - I believe I was
hit by cases where some subvols use redundancy, in which case df goes
completely wrong. I'd have to re-install and re-check to be sure of
exactly what I saw go wrong, though.
Oh yeah that. Not sure what to fix here. df for Btrfs volumes is very literal, whereas df
is actually fibbing when it comes to md raid1. And everyone is used to the fib.
2x 80GB virtual disks, mkfs.btrfs -d raid1 -m raid1:
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdb 160G 56K 158G 1% /mnt
Whereas, 3x 80GB virtual disks, mkfs.btrfs -d raid1 -m raid1:
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdb 240G 56K 160G 1% /mnt
The thing that makes this difficult, md arrays have a fixed raid level. Where as Btrfs
volumes don't. Not implemented yet, but planned is per subvolume and per file raid
levels, so in that case we have to be literal about the reported size of volume being the
combined capacity of all block devices in the Btrfs volume. Or you get a real problem.
Chris Murphy
12:52 a.m.
On Jan 24, 2013, at 9:30 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
2x 80GB virtual disks, mkfs.btrfs -d raid1 -m raid1:
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdb 160G 56K 158G 1% /mnt
Also, copying a 1G file to /mnt, and I end up with:
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sdb 160G 2.0G 150G 2% /mnt
This is consistent as in raid1 mirror, a 1GB file is effectively duplicated and takes up
2GB of the 160GB volume.
The thing I consider a bug, is this:
[root@f18v mnt]# btrfs fi df /mnt
Data, RAID1: total=4.00GB, used=1000.75MB
Because of the RAID1, the amount of chunks allocated for data, raid1 is actually 8GB, and
the amount used is actually 2GB. If this volume wasn't a RAID1, copying a 1GB file
would give identical results to the above, except the RAID1 wouldn't be there. So we
have df being literal, and btrfs fi df itself being secret decoder ringy. Not cool. But I
think this is a known area needing improvement.
Chris Murphy
4132
days inactive
4141
days old
51 comments
29 participants
participants (29)
-
Adam Williamson -
Chris Murphy -
Clyde E. Kunkel -
David Lehman -
Eric Sandeen -
Garry Williams -
Gene Czarcinski -
Ian Malone -
Jan Kratochvil -
Jochen Schmitt -
Josef Bacik -
Josh Boyer -
Josh Stone -
Jóhann B. Guðmundsson -
Kevin Fenzi -
M. Edward (Ed) Borasky -
Marc Deop Argemí -
Marcela Mašláňová -
Matej Cepl -
Peter Robinson -
Przemek Klosowski -
Rahul Sundaram -
Ralf Corsepius -
Reartes Guillermo -
Ric Wheeler -
Richard W.M. Jones -
William -
Zach Brown -
Álvaro Castillo