Re: Status to make btsfs to the standard filesystem of Fedora
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Jan 24, 2013, at 5:44 PM, Adam Williamson awill...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Thu, 2013-01-24 at 19:56 -0700, Chris Murphy wrote: On Jan 24, 2013, at 5:44 PM, Adam Williamson awill...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Jan 24, 2013, at 8:27 PM, Adam Williamson awill...@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/sdb160G 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/sdb240G 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Jan 24, 2013, at 9:30 PM, Chris Murphy li...@colorremedies.com wrote: 2x 80GB virtual disks, mkfs.btrfs -d raid1 -m raid1: # df -h Filesystem Size Used Avail Use% Mounted on /dev/sdb160G 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/sdb160G 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On 01/16/2013 12:18 PM, Josef Bacik wrote: On Wed, Jan 16, 2013 at 3:53 AM, Jochen Schmitt joc...@herr-schmitt.de mailto:joc...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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%20btrfslist_id=1028381 ? Matěj -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On 01/18/2013 01:00 AM, M. Edward (Ed) Borasky wrote: On Thu, Jan 17, 2013 at 3:10 PM, Marc Deop Argemí m...@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@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On 18 January 2013 01:19, Rahul Sundaram methe...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On 18 January 2013 17:19, Rahul Sundaram methe...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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.kratoch...@redhat.com mailto:jan.kratoch...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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 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: Status to make btsfs to the standard filesystem of Fedora
On Thu, Jan 17, 2013 at 3:10 PM, Marc Deop Argemí m...@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@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? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Status to make btsfs to the standard filesystem of Fedora
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Wed, Jan 16, 2013 at 8:22 AM, Jan Kratochvil jan.kratoch...@redhat.comwrote: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On 1/16/13 10:04 AM, Rahul Sundaram wrote: On Wed, Jan 16, 2013 at 8:22 AM, Jan Kratochvil jan.kratoch...@redhat.com mailto:jan.kratoch...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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.kratoch...@redhat.com mailto:jan.kratoch...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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? Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On 01/16/2013 12:00 PM, Rahul Sundaram wrote: snip I haven't seen any recent activity in Fedora from him. Have you? Rahul Some patches on the btrfs list on Jan 7 and 8, 2013. -- Regards, OldFart -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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.) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Wed, Jan 16, 2013 at 12:00 PM, Rahul Sundaram methe...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Wed, Jan 16, 2013 at 3:53 AM, Jochen Schmitt joc...@herr-schmitt.dewrote: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Wed, Jan 16, 2013 at 1:12 PM, Zach Brown z...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Wed, 16 Jan 2013 12:18:37 -0500 Josef Bacik jo...@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 signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Wed, Jan 16, 2013 at 1:50 PM, Richard W.M. Jones rjo...@redhat.comwrote: 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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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 rjo...@redhat.comwrote: 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Wed, Jan 16, 2013 at 9:11 PM, Richard W.M. Jones rjo...@redhat.comwrote: 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 rjo...@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@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Wed, 2013-01-16 at 13:17 -0700, Kevin Fenzi wrote: On Wed, 16 Jan 2013 12:18:37 -0500 Josef Bacik jo...@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=vindexsearch=0x3C0AC6DAB2F928A2 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: Status to make btsfs to the standard filesystem of Fedora
On Thu, 17 Jan 2013 07:46:34 +1030 William Brown will...@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 signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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 jo...@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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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=vindexsearch=0x3C0AC6DAB2F928A2 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: Status to make btsfs to the standard filesystem of Fedora
On Thu, 17 Jan 2013 08:13:07 +1030 William Brown will...@firstyear.id.au wrote: ID 258 gen 56580 top level 5 path FS_TREE/root I take it then that subvolid 258 is marked as / in your fstab? yes, via a subvol=root fstab entry. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Wed, Jan 16, 2013 at 12:18 PM, Richard W.M. Jones rjo...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
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. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Status to make btsfs to the standard filesystem of Fedora
On Jan 16, 2013, at 3:07 PM, Peter Robinson pbrobin...@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 ke...@scrye.com wrote: On Thu, 17 Jan 2013 08:13:07 +1030 William Brown will...@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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
