Re: default file system, was: Comparison to Workstation Technical Specification
On Tue, Mar 04, 2014 at 05:44:14PM -0600, Jon wrote: On the rel-eng side we are not using anaconda to compose the ARM images because we cannot put Anaconda into koji tasks, so instead we use appliance-tools for ARM images. There should be a new koji release _real soon now_ which will include Anaconda via ImageFactory. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Mon, Mar 03, 2014 at 07:05:22PM -0800, Adam Williamson wrote: On Mon, 2014-03-03 at 08:59 -0500, Stephen Gallagher wrote: Now, if you want to talk about having some sort of click-through for I want to try out some experimental options without going all the way to customizing my layout manually, that (to me) needs to be a different, third path. But listing it directly alongside the default gives a false expectation. Custom partitioning actually already provides this path. It would probably be helpful for everyone following this debate to grab a VM and do a few test installs of a recent F21 nightly, so everyone's clear on the UI we're actually debating. I've actually been trying that, but (at least for network installs) I'm blocked on: https://bugzilla.redhat.com/show_bug.cgi?id=1063245 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
OpenQA [was Re: default file system, was: Comparison to Workstation Technical] Specification
On Mon, Mar 03, 2014 at 06:55:44PM -0800, Adam Williamson wrote: I just want to make sure anyone who wants to do this goes in with an accurate knowledge of the work that's likely to be involved. I also want to explain that the folks we have in QA already who are interested in working on tools are already full-time working on other things, and yes we have considered OpenQA (and various other GUI automation frameworks, and various other possible uses of our time apart from working on Taskotron and the other tools we're working on), and come to the conclusion that the stuff we're working on right now really is the most important stuff to be working on right now. We certainly do welcome anyone who wants to spend some of their spare cycles working on OTHER things, though. :) I'm not trying to undo your welcome :) but, also, one completed QA automation framework is approximately 18,000,000× more valuable than two partially-completed ones, so if anyone is interested in this in general but hasn't gotten started, finding where you could contribute to Taskotron would be *even more* helpful. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: OpenQA [was Re: default file system, was: Comparison to Workstation Technical] Specification
On Tue, 2014-03-04 at 07:51 -0500, Matthew Miller wrote: On Mon, Mar 03, 2014 at 06:55:44PM -0800, Adam Williamson wrote: I just want to make sure anyone who wants to do this goes in with an accurate knowledge of the work that's likely to be involved. I also want to explain that the folks we have in QA already who are interested in working on tools are already full-time working on other things, and yes we have considered OpenQA (and various other GUI automation frameworks, and various other possible uses of our time apart from working on Taskotron and the other tools we're working on), and come to the conclusion that the stuff we're working on right now really is the most important stuff to be working on right now. We certainly do welcome anyone who wants to spend some of their spare cycles working on OTHER things, though. :) I'm not trying to undo your welcome :) but, also, one completed QA automation framework is approximately 18,000,000× more valuable than two partially-completed ones, so if anyone is interested in this in general but hasn't gotten started, finding where you could contribute to Taskotron would be *even more* helpful. Hum, well. OpenQA exists and does what it does already; there wouldn't be a lot of duplication going on. Taskotron is a far, far more generic framework; it could certainly be used to do GUI automation testing, probably by using something like dogtail inside it, but there'd be a lot of bits to build, I think. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 02/28/2014 03:45 PM, Adam Williamson wrote: As a server WG member I voted +1 on XFS as I have no particular objection to XFS as a filesystem, but I do think it seems a bit sub-optimal for us to wind up with server and desktop having defaults that are very similar but slightly different, for no apparently great reason. This may be a historical bias. XFS is a large code base (*), which means two things: a larger bug surface, and a larger memory footprint that used to be a problem for personal desktop-type machines but less so for better endowed servers. I understand that by now XFS got so much exercise that its robustness is unimpeachable. As to the size, I see that while the latest XFS kernel module is one of the larger kernel modules around, it probably is no longer significant on today's multi-GB systems---the extra megabyte at current memory prices is just a one cent increase in the system cost, after all. Having said that, I don't use XFS nowadays so I don't know how much more memory it allocates in typical use---can anyone comment on the actual memory footprint of running XFS? I am pretty sure that ext4 is a built-in module in Fedora kernels, as well as in the boot environment; making XFS the default will require also building it in, pretty much forever, while we still need extXX, and whatever comes next (btrfs?). I am OK with that, though. (*) 2.9MB of XFS source code vs 1.3MB in ext4 dirs (**) xfs.ko is 1.3MB -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Tue, Mar 4, 2014 at 4:26 PM, Przemek Klosowski przemek.klosow...@nist.gov wrote: I am pretty sure that ext4 is a built-in module in Fedora kernels, as well as in the boot environment; making XFS the default will require also building it in, pretty much forever, while we still need extXX, and whatever comes next (btrfs?). I am OK with that, though. No, it won't require building it into the kernel. People use XFS and btrfs for / today with them being built as modules. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
Once upon a time, Przemek Klosowski przemek.klosow...@nist.gov said: I understand that by now XFS got so much exercise that its robustness is unimpeachable. As to the size, I see that while the latest XFS kernel module is one of the larger kernel modules around, it probably is no longer significant on today's multi-GB systems---the extra megabyte at current memory prices is just a one cent increase in the system cost, after all. That is true for some systems, but not necessarily for all. Many ARM systems are RAM-constrained, and some people using lots of server VMs also like to keep each VM as small as practical. I am pretty sure that ext4 is a built-in module in Fedora kernels, as well as in the boot environment; making XFS the default will require also building it in, pretty much forever, while we still need extXX, and whatever comes next (btrfs?). I am OK with that, though. Not really, it is only recent Fedora releases that have built ext4 into the kernel. We went many years with ext3 being loaded as a module (was it ever built in?); ext4 was added more for convenience. Having the common stuff that's going to be loaded on something like 99% of Fedora systems anyway built into the kernel is slightly more efficient and more convenient. If we have a split between filesystems between products, then it probably doesn't make sense to build any of them into the kernel anymore (well, assuming they all use the same kernel RPMs). -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Tue, Mar 4, 2014 at 4:35 PM, Chris Adams li...@cmadams.net wrote: Once upon a time, Przemek Klosowski przemek.klosow...@nist.gov said: I am pretty sure that ext4 is a built-in module in Fedora kernels, as well as in the boot environment; making XFS the default will require also building it in, pretty much forever, while we still need extXX, and whatever comes next (btrfs?). I am OK with that, though. Not really, it is only recent Fedora releases that have built ext4 into the kernel. We went many years with ext3 being loaded as a module (was it ever built in?); ext4 was added more for convenience. Having the common stuff that's going to be loaded on something like 99% of Fedora systems anyway built into the kernel is slightly more efficient and more convenient. If we have a split between filesystems between products, then it probably doesn't make sense to build any of them into the kernel anymore (well, assuming they all use the same kernel RPMs). Cloud and Workstation are both looking likely to use ext4. Server differs with XFS. We're likely to just leave things as-is for the near term. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 03/04/2014 11:26 PM, Przemek Klosowski wrote: On 02/28/2014 03:45 PM, Adam Williamson wrote: As a server WG member I voted +1 on XFS as I have no particular objection to XFS as a filesystem, but I do think it seems a bit sub-optimal for us to wind up with server and desktop having defaults that are very similar but slightly different, for no apparently great reason. This may be a historical bias. XFS is a large code base (*), which means two things: a larger bug surface, and a larger memory footprint that used to be a problem for personal desktop-type machines but less so for better endowed servers. I understand that by now XFS got so much exercise that its robustness is unimpeachable. As to the size, I see that while the latest XFS kernel module is one of the larger kernel modules around, it probably is no longer significant on today's multi-GB systems---the extra megabyte at current memory prices is just a one cent increase in the system cost, after all. Having said that, I don't use XFS nowadays so I don't know how much more memory it allocates in typical use---can anyone comment on the actual memory footprint of running XFS? I am pretty sure that ext4 is a built-in module in Fedora kernels, as well as in the boot environment; making XFS the default will require also building it in, pretty much forever, while we still need extXX, and whatever comes next (btrfs?). I am OK with that, though. (*) 2.9MB of XFS source code vs 1.3MB in ext4 dirs (**) xfs.ko is 1.3MB You need to count the jbd2 code for ext4 as well, Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Mon, Mar 3, 2014 at 9:01 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 3, 2014, at 4:57 PM, Jon jdisn...@gmail.com wrote: We no longer release Fedora ARM rootfs tarballs, too hard to educate people to do the right thing with ACL's, xattrs, selinux, etc... Anyhow, it's actually a great way to ship a Fedora rootfs... just shrink the filesystem down to the smallest size, and allow the user to simply resize2fs the image into their storage. Well unfortunately it's not default ready yet, so it's a bit off-topic. But I see your example as a particularly good use case for several features including btrfs send to a file (restored with btrfs receive onto a new file system of whatever size); and btrfs seed device. This would not be possible with XFS for the server variant of Fedora-ARM, and I feel represents a significant challenge to the ARM team. I'm a bit lost, but I think this is important to understand. Does the Server product anaconda default somehow affect the armv7hl raw.xz images you release? Is there a way to decouple this? Because Fedora ARM doesn't really use anaconda at all, do you? On the rel-eng side we are not using anaconda to compose the ARM images because we cannot put Anaconda into koji tasks, so instead we use appliance-tools for ARM images. (we used to use Anaconda to compose the ARM images until recently) We still use kickstart, and for the ARM case we will do our best to have 1:1 parity with the x86_64 server variant defaults. Part of becoming PA is a commitment to keep things the same, as much as possible, in all the places. So it's important to consider the impact of XFS on ARM. That said, my example about resizing the rootfs into the target system will probably still work. But our process on the rel-eng side might be complicated slightly... more of an annoyance than a major blocker. If the anaconda default fs somehow binds your images to using the same thing, does it make sense to consider making XFS the default also contingent on using lvmthinp? I would characterize lvm thin provisioning as a great way to balance the situation, given the facts about XFS shrinking. Not sure about making it contingent. Thin provisioning sounds great, but I'm not sure it replaces the ability to shrink in all situations, but it appears to negate many of the situations I've mentioned, but not all. For example? When people remove FC san luns from a over-subscribed VG, and are then forced shrink the LV's and ext4's. I would imagine people turning their ARM dev board into a home NAS or some similar storage kit, and the linear scale-up of XFS is really appealing. ARM gluster cluster :-) Yes! Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Jon -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 3/4/14, 3:43 PM, Ric Wheeler wrote: On 03/04/2014 11:26 PM, Przemek Klosowski wrote: On 02/28/2014 03:45 PM, Adam Williamson wrote: As a server WG member I voted +1 on XFS as I have no particular objection to XFS as a filesystem, but I do think it seems a bit sub-optimal for us to wind up with server and desktop having defaults that are very similar but slightly different, for no apparently great reason. This may be a historical bias. XFS is a large code base (*), which means two things: a larger bug surface, and a larger memory footprint that used to be a problem for personal desktop-type machines but less so for better endowed servers. I understand that by now XFS got so much exercise that its robustness is unimpeachable. As to the size, I see that while the latest XFS kernel module is one of the larger kernel modules around, it probably is no longer significant on today's multi-GB systems---the extra megabyte at current memory prices is just a one cent increase in the system cost, after all. Having said that, I don't use XFS nowadays so I don't know how much more memory it allocates in typical use---can anyone comment on the actual memory footprint of running XFS? I am pretty sure that ext4 is a built-in module in Fedora kernels, as well as in the boot environment; making XFS the default will require also building it in, pretty much forever, while we still need extXX, and whatever comes next (btrfs?). I am OK with that, though. (*) 2.9MB of XFS source code vs 1.3MB in ext4 dirs (**) xfs.ko is 1.3MB You need to count the jbd2 code for ext4 as well, Ric FWIW, I we looked at lines of code vs. megabytes of source, back in 3.4, and did a blog post about the trend lines: http://sandeen.net/wordpress/computers/linux-filesystems-loc-update/ I did count jbd2 in that, as well as the common mbcache code which in truth is only used for the extN filesystems. I suppose I need to do another update :) -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 2 March 2014 14:56, Ric Wheeler rwhee...@redhat.com wrote: On 03/02/2014 01:17 PM, Ian Malone wrote: Can we get some definition of legacy here? kernel/nfs-utils versions? I'd have to check what I can share. If it helps: not current RHEL or recent Fedora, until recently some that were over five years old. Also this comment in the XFS FAQ: Beware that some old programs might have problems reading 64bit inodes which seems to be related to stat vs stat64, there are some old programs that might require us to modify. Just to be clear, defaults are only important when you install. I don't think anyone is suggesting compiling out the ext4 code from the kernel so this should be of zero impact to someone running a file year old system who wants to upgrade to something modern. If you need to stay on that five year old system and not upgrade, I am not sure I understand why it would be a reasonable example. As other people have mentioned, there are ways to create an XFS instance that does not use 64 bit inodes (but that is *not* a sane default since the problems you refer to are not common with modern apps). Yes, I maybe wasn't clear in my first email and the context has been a bit lost in people following up details. My point was really that there may be reasons for selecting a particular fs in a server context[1] and that people setting up servers will often want to change from the defaults. What seemed to be happening looked the wrong way around: talk about the workstation defaults being the same as the server ones, for not much more reason than the server decision was taken first. It now looks like the consensus is it *could* be different. [1] Aside: it's an NFS server with some older clients, so upgrading the server while retaining the clients would be a perfectly feasible scenario, and actually ext4 seems to be working as well for us as XFS did. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/01/2014 04:18 PM, Chris Murphy wrote: On Mar 1, 2014, at 1:19 PM, Jon jdisn...@gmail.com wrote: The inability to shrink or reduce XFS is rather disappointing. I've seen a few sarcastic remarks along the lines of (paraphrased): why would anyone ever want to shrink a volume? In the context of server, and default installs, why is a valid question. I just want to reiterate that this is what we are recommending for a purely default installation. This is what you get only if you decide not to customize your partitioning in any way. I expect this to be the exception, not the rule, for Server deployments. However, we want to have something in place for the Let's try this out and see what happens crowd of potential converts. In that case, I think having a set of defaults focused on performance and scalability will go a longer way down the path of bringing people around than filesystem shrinking. That's not to say that there's anything inherently wrong with EXT4. We just feel that XFS is better suited to our default offering. People do shrink volumes, and this lack of flexibility is an important consideration I feel was ignored in the Server WG decision. What is the use case for volume shrinking in a server context? Dual boot is a total edge case for servers. for me personally, I'm not sure any performance gains are enough to compensate for the lack of flexibility. Considering that LVM has the ability to resize volumes, ext4 pairs very well, Unless you use system-storage-manager, you might refresh the steps required to do an ext4 on LVM resize. I don't think the person who understands how to do that is really the target audience for default installs. and I'm skeptical thin provisioning does enough make-up for the lack of XFS shrinking. It even makes up for ext4 shrinking in two ways. 1. Instead of making an LV smaller than possibly needed, make it the size it probably should be from the start. It only consumes extents from the thinpool as needed. 2. Upon significant file deletion, fstrim returns unused extents back to the thinpool. This is faster, more efficient, and less fragile than file system shrink. Again, the problem is that commands are a bit esoteric, but maybe system-storage-manager can help out with this once it support thin provisioning. So my question to the Server WG, did anybody consider this aspect of XFS (lack of shrinking) before making the decision? What were the highest reasons for NOT staying with EXT4? I realize the thread has well over 100 emails in it, but it was considered. The simple explanation why XFS was chosen is because it was well vetted by Red Hat storage experts for use as the default in RHEL 7 - and I understand that sgallagh is working on a summary of those reasons, which would apply here as well. I'd say top on the I asked Ric Wheeler (the lead for Red Hat's storage and filesystem) to provide some justifications. He responded elsewhere in this thread, which I'll repeat here in case it was missed: XFS has many advantages: * best performance for most workloads (especially with high speed storage and larger number of cores) * tends to be less CPU intensive (better optimizations around lock contention, etc) * most robust at large scale - has been run at hundred plus TB sizes for many years (and today's storage is getting way bigger, 16TB is about half a shelf of drives) * XFS is the most common file system in multiple key upstream communities: most common base for ceph, gluster and openstack more broadly * pioneered most of the techniques now in ext4 for performance (like delayed allocation) That said, ext4 has not been standing still: * it has made major advances as well in the past few years in closing in on XFS features * goes toe to toe with XFS in many workloads, especially on smaller storage sizes. It will tend to be faster than XFS with some specific workloads (like single threaded, metadata intensive workloads) * commonly used file system in major sites systems (google, android, RHEL6) I think that having XFS as the default for servers and ext4 as a default for workstations is reasonable. As part of the group that works on both, it won't make our lives any crazier Ric list is XFS is scales linearly as more threads are thrown at it, it's very good at parallelism, and it support project quotas which often obviates the need to create separate file systems as a means of constraining storage usage rather than doing it only by user or group. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMUdLUACgkQeiVVYja6o6MywQCeP9QpKtKw4fRhiFtSZuC5OnHC sLQAn0Fgx2tZZ/KOAR7t1s67Nu6jDBrt =MtyA -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct:
Re: default file system, was: Comparison to Workstation Technical Specification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/01/2014 06:38 PM, Chris Murphy wrote: On Mar 1, 2014, at 3:58 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 01.03.2014 22:55, schrieb poma: On 27.02.2014 01:33, Josef Bacik wrote: Just popping in here to say that btrfs is not ready to be default in Fedora yet. Optional is fine but not default. Thanks, This is actually a good news. Thanks. Now all we need is fair support in the installer. BTRFS as alternative scheme: +1 F-Server +1 F-Workstation one of the BTRFS maintainers explains is is *not* ready and you start we need in context of BTRFS? strange logic Josef said it's not ready to be default. Poma suggested making it available as an alternate to whatever the default is, which is consistent with how Fedora has been for three releases. His suggestion is still fewer permutations than the partition scheme outcomes in Fedora 20; and is about the same or on par with Fedora 18/19, but still one more than oldui. One of the things that we have been seriously discussing here is that non-default options (particularly those known not to be ready) do not need or deserve to be presented with the same prominence as other options. In my opinion, only the default layout should be provided prominently. Other choices (such as btrfs) should be available as part of the custom layout options. Users should be permitted to install it (and without annoying hoops), but they are not entitled to us developing a best effort default of a technology we aren't sure they should be using, which is essentially what the btrfs drop-down in Fedora 20 meant. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMUdwkACgkQeiVVYja6o6NHKACbBZBsXDeoxOQIVZZvOHyY2vjK l7sAoJHHB4OVRnyhaRclhuFebS+spACp =aTE0 -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Mar 3, 2014 7:34 AM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/01/2014 06:38 PM, Chris Murphy wrote: On Mar 1, 2014, at 3:58 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 01.03.2014 22:55, schrieb poma: On 27.02.2014 01:33, Josef Bacik wrote: Just popping in here to say that btrfs is not ready to be default in Fedora yet. Optional is fine but not default. Thanks, This is actually a good news. Thanks. Now all we need is fair support in the installer. BTRFS as alternative scheme: +1 F-Server +1 F-Workstation one of the BTRFS maintainers explains is is *not* ready and you start we need in context of BTRFS? strange logic Josef said it's not ready to be default. Poma suggested making it available as an alternate to whatever the default is, which is consistent with how Fedora has been for three releases. His suggestion is still fewer permutations than the partition scheme outcomes in Fedora 20; and is about the same or on par with Fedora 18/19, but still one more than oldui. One of the things that we have been seriously discussing here is that non-default options (particularly those known not to be ready) do not need or deserve to be presented with the same prominence as other options. In my opinion, only the default layout should be provided prominently. Other choices (such as btrfs) should be available as part of the custom layout options. Users should be permitted to install it (and without annoying hoops), but they are not entitled to us developing a best effort default of a technology we aren't sure they should be using, which is essentially what the btrfs drop-down in Fedora 20 meant. I'm not saying it isn't ready at all, just not the default. I and others still need a way to install on to btrfs if they need to, and frankly it is good enough for most people to use. I hope we aren't talking about taking that option away completely right? Thanks, Josef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/03/2014 08:32 AM, Josef Bacik wrote: On Mar 3, 2014 7:34 AM, Stephen Gallagher sgall...@redhat.com mailto:sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/01/2014 06:38 PM, Chris Murphy wrote: On Mar 1, 2014, at 3:58 PM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: Am 01.03.2014 22:55, schrieb poma: On 27.02.2014 01:33, Josef Bacik wrote: Just popping in here to say that btrfs is not ready to be default in Fedora yet. Optional is fine but not default. Thanks, This is actually a good news. Thanks. Now all we need is fair support in the installer. BTRFS as alternative scheme: +1 F-Server +1 F-Workstation one of the BTRFS maintainers explains is is *not* ready and you start we need in context of BTRFS? strange logic Josef said it's not ready to be default. Poma suggested making it available as an alternate to whatever the default is, which is consistent with how Fedora has been for three releases. His suggestion is still fewer permutations than the partition scheme outcomes in Fedora 20; and is about the same or on par with Fedora 18/19, but still one more than oldui. One of the things that we have been seriously discussing here is that non-default options (particularly those known not to be ready) do not need or deserve to be presented with the same prominence as other options. In my opinion, only the default layout should be provided prominently. Other choices (such as btrfs) should be available as part of the custom layout options. Users should be permitted to install it (and without annoying hoops), but they are not entitled to us developing a best effort default of a technology we aren't sure they should be using, which is essentially what the btrfs drop-down in Fedora 20 meant. I'm not saying it isn't ready at all, just not the default. I and others still need a way to install on to btrfs if they need to, and frankly it is good enough for most people to use. I hope we aren't talking about taking that option away completely right? Thanks, I said they should be permitted to install it (and without annoying hoops). However, it's a *bad* user experience to have a guided path option for a feature we aren't ready to promote as the preferred approach. Particularly because QA testing has to occur on all guided paths. Also, let's be clear here: using the guided path in the UI of a Fedora Server install *will* be the exceptional case. I fully expect that most deployments will occur with either a kickstart or a manual partitioning effort. The only real purpose to a default, guided path in the Fedora Server UI is to provide A) the common setup we know people use so that QA is focusing its testing in the right direction and B) so that newcomers have something stable to try it out. So if you were asking me Are we removing btrfs from the install options completely?, the answer is a resounding NO. However, if you're asking Are we removing btrfs from the drop-down of simple-install layouts?, my personal recommendation is yes. This is not a slight against btrfs; if you read the rest of my emails, I'm proposing to do away with this drop-down entirely, including the ext4 and non-LVM approaches so that we really only have The default way and create your own destiny choices. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMUhusACgkQeiVVYja6o6O6lgCdFNsmUwQmR43o4xt791dwpL5A YV4AnAqYlw3UM/6z5I+oisZCsrCDw2MJ =ptlS -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 03/03/2014 03:43 PM, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/03/2014 08:32 AM, Josef Bacik wrote: On Mar 3, 2014 7:34 AM, Stephen Gallagher sgall...@redhat.com mailto:sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/01/2014 06:38 PM, Chris Murphy wrote: On Mar 1, 2014, at 3:58 PM, Reindl Harald h.rei...@thelounge.net mailto:h.rei...@thelounge.net wrote: Am 01.03.2014 22:55, schrieb poma: On 27.02.2014 01:33, Josef Bacik wrote: Just popping in here to say that btrfs is not ready to be default in Fedora yet. Optional is fine but not default. Thanks, This is actually a good news. Thanks. Now all we need is fair support in the installer. BTRFS as alternative scheme: +1 F-Server +1 F-Workstation one of the BTRFS maintainers explains is is *not* ready and you start we need in context of BTRFS? strange logic Josef said it's not ready to be default. Poma suggested making it available as an alternate to whatever the default is, which is consistent with how Fedora has been for three releases. His suggestion is still fewer permutations than the partition scheme outcomes in Fedora 20; and is about the same or on par with Fedora 18/19, but still one more than oldui. One of the things that we have been seriously discussing here is that non-default options (particularly those known not to be ready) do not need or deserve to be presented with the same prominence as other options. In my opinion, only the default layout should be provided prominently. Other choices (such as btrfs) should be available as part of the custom layout options. Users should be permitted to install it (and without annoying hoops), but they are not entitled to us developing a best effort default of a technology we aren't sure they should be using, which is essentially what the btrfs drop-down in Fedora 20 meant. I'm not saying it isn't ready at all, just not the default. I and others still need a way to install on to btrfs if they need to, and frankly it is good enough for most people to use. I hope we aren't talking about taking that option away completely right? Thanks, I said they should be permitted to install it (and without annoying hoops). However, it's a *bad* user experience to have a guided path option for a feature we aren't ready to promote as the preferred approach. Particularly because QA testing has to occur on all guided paths. Also, let's be clear here: using the guided path in the UI of a Fedora Server install *will* be the exceptional case. I fully expect that most deployments will occur with either a kickstart or a manual partitioning effort. The only real purpose to a default, guided path in the Fedora Server UI is to provide A) the common setup we know people use so that QA is focusing its testing in the right direction and B) so that newcomers have something stable to try it out. So if you were asking me Are we removing btrfs from the install options completely?, the answer is a resounding NO. However, if you're asking Are we removing btrfs from the drop-down of simple-install layouts?, my personal recommendation is yes. I disagree - why would we remove the drop down option? That would make it exceedingly hard and rare for casual users to install and test. Basically, our Fedora btrfs user base would drop to nothing. Making it easy to test is a critical part of taking btrfs up to the next level of stability! Ric This is not a slight against btrfs; if you read the rest of my emails, I'm proposing to do away with this drop-down entirely, including the ext4 and non-LVM approaches so that we really only have The default way and create your own destiny choices. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/03/2014 08:51 AM, Ric Wheeler wrote: On 03/03/2014 03:43 PM, Stephen Gallagher wrote: So if you were asking me Are we removing btrfs from the install options completely?, the answer is a resounding NO. However, if you're asking Are we removing btrfs from the drop-down of simple-install layouts?, my personal recommendation is yes. I disagree - why would we remove the drop down option? That would make it exceedingly hard and rare for casual users to install and test. Basically, our Fedora btrfs user base would drop to nothing. Making it easy to test is a critical part of taking btrfs up to the next level of stability! It's a matter of user experience, here. By presenting something in the guided drop-down, we are effectively asserting that they are of equal utility and support. This is *not* the reality. Now, if you want to talk about having some sort of click-through for I want to try out some experimental options without going all the way to customizing my layout manually, that (to me) needs to be a different, third path. But listing it directly alongside the default gives a false expectation. Now, this might be as simple as changing the modern drop-down from * EXT4 * BTRFS * XFS [] Use LVM To something like: * XFS-LVM (Recommended) * XFS * EXT4-LVM * EXT4 * BTRFS (Experimental) But even still, Fedora QA is at least ostensibly supposed to test all guided paths and best-effort of custom paths. This is more paths than are strictly necessary, especially considering that we don't expect many people to actually USE the guided paths (in favor of custom and/or kickstart). -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMUirgACgkQeiVVYja6o6NxugCfcyMPtcfL3Xts+3Xf8SEB5x8q sl4AoJoT6IU4a7iszioRpXinNjgvt8TQ =6t2/ -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Mon, Mar 3, 2014 at 8:59 AM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/03/2014 08:51 AM, Ric Wheeler wrote: On 03/03/2014 03:43 PM, Stephen Gallagher wrote: So if you were asking me Are we removing btrfs from the install options completely?, the answer is a resounding NO. However, if you're asking Are we removing btrfs from the drop-down of simple-install layouts?, my personal recommendation is yes. I disagree - why would we remove the drop down option? That would make it exceedingly hard and rare for casual users to install and test. Basically, our Fedora btrfs user base would drop to nothing. Making it easy to test is a critical part of taking btrfs up to the next level of stability! It's a matter of user experience, here. By presenting something in the guided drop-down, we are effectively asserting that they are of equal utility and support. This is *not* the reality. Now, if you want to talk about having some sort of click-through for I want to try out some experimental options without going all the way to customizing my layout manually, that (to me) needs to be a different, third path. But listing it directly alongside the default gives a false expectation. Now, this might be as simple as changing the modern drop-down from * EXT4 * BTRFS * XFS [] Use LVM To something like: * XFS-LVM (Recommended) * XFS * EXT4-LVM * EXT4 * BTRFS (Experimental) But even still, Fedora QA is at least ostensibly supposed to test all guided paths and best-effort of custom paths. This is more paths than are strictly necessary, especially considering that we don't expect many people to actually USE the guided paths (in favor of custom and/or kickstart). Ok I was just confused as I haven't done a normal install in a few releases. So you can still get to btrfs going through some new custom layout option but you want to remove the install onto btrfs easy button in the normal guided option? I'm ok with this, I just want to make sure that I/users don't have to jump through icantbelieveitsnotbtr hoops to install onto btrfs. Thanks, Josef -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 03/03/2014 04:06 PM, Josef Bacik wrote: On Mon, Mar 3, 2014 at 8:59 AM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/03/2014 08:51 AM, Ric Wheeler wrote: On 03/03/2014 03:43 PM, Stephen Gallagher wrote: So if you were asking me Are we removing btrfs from the install options completely?, the answer is a resounding NO. However, if you're asking Are we removing btrfs from the drop-down of simple-install layouts?, my personal recommendation is yes. I disagree - why would we remove the drop down option? That would make it exceedingly hard and rare for casual users to install and test. Basically, our Fedora btrfs user base would drop to nothing. Making it easy to test is a critical part of taking btrfs up to the next level of stability! It's a matter of user experience, here. By presenting something in the guided drop-down, we are effectively asserting that they are of equal utility and support. This is *not* the reality. Now, if you want to talk about having some sort of click-through for I want to try out some experimental options without going all the way to customizing my layout manually, that (to me) needs to be a different, third path. But listing it directly alongside the default gives a false expectation. Now, this might be as simple as changing the modern drop-down from * EXT4 * BTRFS * XFS [] Use LVM To something like: * XFS-LVM (Recommended) * XFS * EXT4-LVM * EXT4 * BTRFS (Experimental) But even still, Fedora QA is at least ostensibly supposed to test all guided paths and best-effort of custom paths. This is more paths than are strictly necessary, especially considering that we don't expect many people to actually USE the guided paths (in favor of custom and/or kickstart). Ok I was just confused as I haven't done a normal install in a few releases. So you can still get to btrfs going through some new custom layout option but you want to remove the install onto btrfs easy button in the normal guided option? I'm ok with this, I just want to make sure that I/users don't have to jump through icantbelieveitsnotbtr hoops to install onto btrfs. Thanks, Josef I am fine with something like what is proposed by Steve above - let users have the GUI present an option that gives preference to the default without totally hiding other options. Thanks! Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/03/2014 09:06 AM, Josef Bacik wrote: On Mon, Mar 3, 2014 at 8:59 AM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/03/2014 08:51 AM, Ric Wheeler wrote: On 03/03/2014 03:43 PM, Stephen Gallagher wrote: So if you were asking me Are we removing btrfs from the install options completely?, the answer is a resounding NO. However, if you're asking Are we removing btrfs from the drop-down of simple-install layouts?, my personal recommendation is yes. snip Ok I was just confused as I haven't done a normal install in a few releases. So you can still get to btrfs going through some new custom layout option but you want to remove the install onto btrfs easy button in the normal guided option? I'm ok with this, I just want to make sure that I/users don't have to jump through icantbelieveitsnotbtr hoops to install onto btrfs. Thanks, Right, we're absolutely not adding any hoops to installing onto btrfs above and beyond what we do for, say, ext4. There would be one simple clickthrough Just give me the defaults or else I'll set up my partitions how I want them. Btrfs would be no harder to select in that latter approach than any other FS. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMUjzkACgkQeiVVYja6o6PzDwCgoAp8C2XJvpLTBPLIX+x/80jV XbYAoKyuaARmC0oLkAtBGyDyr2iIKsci =Qjpe -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/03/2014 09:16 AM, Ric Wheeler wrote: On 03/03/2014 04:06 PM, Josef Bacik wrote: On Mon, Mar 3, 2014 at 8:59 AM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/03/2014 08:51 AM, Ric Wheeler wrote: On 03/03/2014 03:43 PM, Stephen Gallagher wrote: So if you were asking me Are we removing btrfs from the install options completely?, the answer is a resounding NO. However, if you're asking Are we removing btrfs from the drop-down of simple-install layouts?, my personal recommendation is yes. I disagree - why would we remove the drop down option? That would make it exceedingly hard and rare for casual users to install and test. Basically, our Fedora btrfs user base would drop to nothing. Making it easy to test is a critical part of taking btrfs up to the next level of stability! It's a matter of user experience, here. By presenting something in the guided drop-down, we are effectively asserting that they are of equal utility and support. This is *not* the reality. Now, if you want to talk about having some sort of click-through for I want to try out some experimental options without going all the way to customizing my layout manually, that (to me) needs to be a different, third path. But listing it directly alongside the default gives a false expectation. Now, this might be as simple as changing the modern drop-down from * EXT4 * BTRFS * XFS [] Use LVM To something like: * XFS-LVM (Recommended) * XFS * EXT4-LVM * EXT4 * BTRFS (Experimental) But even still, Fedora QA is at least ostensibly supposed to test all guided paths and best-effort of custom paths. This is more paths than are strictly necessary, especially considering that we don't expect many people to actually USE the guided paths (in favor of custom and/or kickstart). Ok I was just confused as I haven't done a normal install in a few releases. So you can still get to btrfs going through some new custom layout option but you want to remove the install onto btrfs easy button in the normal guided option? I'm ok with this, I just want to make sure that I/users don't have to jump through icantbelieveitsnotbtr hoops to install onto btrfs. Thanks, Josef I am fine with something like what is proposed by Steve above - let users have the GUI present an option that gives preference to the default without totally hiding other options. To be clear, I don't really like that option at all. I was presenting it to show how it's not a great user experience. That being said, if everyone else (and especially QA) prefers that approach, I'm certainly flexible on the point. I'm really hoping that the design, user experience, anaconda and QA teams will make their opinions on this known. I know full well that this is not my area of expertise. BCCing a few specific individuals to hopefully get their input. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMUkD0ACgkQeiVVYja6o6Pi+ACfTDwoz8EHV5eztXwIOVz4IBBh JZIAoIWD+NnTHfS6PrIDi+t0eeMVyP5h =+v+e -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Mon, Mar 03, 2014 at 09:22:53AM -0500, Stephen Gallagher wrote: On 03/03/2014 09:16 AM, Ric Wheeler wrote: On 03/03/2014 04:06 PM, Josef Bacik wrote: On Mon, Mar 3, 2014 at 8:59 AM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/03/2014 08:51 AM, Ric Wheeler wrote: On 03/03/2014 03:43 PM, Stephen Gallagher wrote: So if you were asking me Are we removing btrfs from the install options completely?, the answer is a resounding NO. However, if you're asking Are we removing btrfs from the drop-down of simple-install layouts?, my personal recommendation is yes. I disagree - why would we remove the drop down option? That would make it exceedingly hard and rare for casual users to install and test. Basically, our Fedora btrfs user base would drop to nothing. Making it easy to test is a critical part of taking btrfs up to the next level of stability! It's a matter of user experience, here. By presenting something in the guided drop-down, we are effectively asserting that they are of equal utility and support. This is *not* the reality. Now, if you want to talk about having some sort of click-through for I want to try out some experimental options without going all the way to customizing my layout manually, that (to me) needs to be a different, third path. But listing it directly alongside the default gives a false expectation. Now, this might be as simple as changing the modern drop-down from * EXT4 * BTRFS * XFS [] Use LVM To something like: * XFS-LVM (Recommended) * XFS * EXT4-LVM * EXT4 * BTRFS (Experimental) But even still, Fedora QA is at least ostensibly supposed to test all guided paths and best-effort of custom paths. This is more paths than are strictly necessary, especially considering that we don't expect many people to actually USE the guided paths (in favor of custom and/or kickstart). Ok I was just confused as I haven't done a normal install in a few releases. So you can still get to btrfs going through some new custom layout option but you want to remove the install onto btrfs easy button in the normal guided option? I'm ok with this, I just want to make sure that I/users don't have to jump through icantbelieveitsnotbtr hoops to install onto btrfs. Thanks, Josef I am fine with something like what is proposed by Steve above - let users have the GUI present an option that gives preference to the default without totally hiding other options. To be clear, I don't really like that option at all. I was presenting it to show how it's not a great user experience. That being said, if everyone else (and especially QA) prefers that approach, I'm certainly flexible on the point. I'm really hoping that the design, user experience, anaconda and QA teams will make their opinions on this known. I know full well that this is not my area of expertise. BCCing a few specific individuals to hopefully get their input. I agree with Stephen here, assuming I'm understanding him correctly. When you talk about choices in a UI, you start exponentially increasing the number of paths to do basically the same thing. Exposing a filesystem choice to users really degrades the user experience. Does everyone know what a filesystem is? And if they know, do they know what the options are that we are presenting them? Do they know the pros and the cons between them? Do they really care that much? To me it sounds like the goal here is to advertise other filesystem options in the hopes that we get some drive-by interest by people doing first time installs. 10 years of bug reports tell me that people just don't care about that option. A default is exactly that, a default. We should pick a good default that is well supported across all of the architectures that we care about in Fedora. By exposing a filesystem selection option at install time, we're really saying we have that many defaults. Oh, and we need you to understand them so you can pick one. Most people would probably leave that option alone, which begs the question: why have it at all? It's 2014 and we're still holding on to BTRFS as the solution to all of our filesystem problems. That's fine, but it hasn't happened yet. And as long as that's the story, we should expose something that's actually usable and recommended at install time. I really see no value in offering slightly different filesystem options at install time. If we want something different, it should become the new default. (For clarification, the above is speaking about the automatic partitioning code path, not custom partitioning. Custom will likely always involve more knobs and controls for users, and many filesystem types. But that's ok, custom is for those users.) -- David Cantrell dcantr...@redhat.com Manager, Installer Engineering Team Red Hat, Inc. | Westford, MA | EST5EDT -- devel mailing list
Re: default file system, was: Comparison to Workstation Technical Specification
On 03/03/2014 04:40 PM, David Cantrell wrote: On Mon, Mar 03, 2014 at 09:22:53AM -0500, Stephen Gallagher wrote: On 03/03/2014 09:16 AM, Ric Wheeler wrote: On 03/03/2014 04:06 PM, Josef Bacik wrote: On Mon, Mar 3, 2014 at 8:59 AM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/03/2014 08:51 AM, Ric Wheeler wrote: On 03/03/2014 03:43 PM, Stephen Gallagher wrote: So if you were asking me Are we removing btrfs from the install options completely?, the answer is a resounding NO. However, if you're asking Are we removing btrfs from the drop-down of simple-install layouts?, my personal recommendation is yes. I disagree - why would we remove the drop down option? That would make it exceedingly hard and rare for casual users to install and test. Basically, our Fedora btrfs user base would drop to nothing. Making it easy to test is a critical part of taking btrfs up to the next level of stability! It's a matter of user experience, here. By presenting something in the guided drop-down, we are effectively asserting that they are of equal utility and support. This is *not* the reality. Now, if you want to talk about having some sort of click-through for I want to try out some experimental options without going all the way to customizing my layout manually, that (to me) needs to be a different, third path. But listing it directly alongside the default gives a false expectation. Now, this might be as simple as changing the modern drop-down from * EXT4 * BTRFS * XFS [] Use LVM To something like: * XFS-LVM (Recommended) * XFS * EXT4-LVM * EXT4 * BTRFS (Experimental) But even still, Fedora QA is at least ostensibly supposed to test all guided paths and best-effort of custom paths. This is more paths than are strictly necessary, especially considering that we don't expect many people to actually USE the guided paths (in favor of custom and/or kickstart). Ok I was just confused as I haven't done a normal install in a few releases. So you can still get to btrfs going through some new custom layout option but you want to remove the install onto btrfs easy button in the normal guided option? I'm ok with this, I just want to make sure that I/users don't have to jump through icantbelieveitsnotbtr hoops to install onto btrfs. Thanks, Josef I am fine with something like what is proposed by Steve above - let users have the GUI present an option that gives preference to the default without totally hiding other options. To be clear, I don't really like that option at all. I was presenting it to show how it's not a great user experience. That being said, if everyone else (and especially QA) prefers that approach, I'm certainly flexible on the point. I'm really hoping that the design, user experience, anaconda and QA teams will make their opinions on this known. I know full well that this is not my area of expertise. BCCing a few specific individuals to hopefully get their input. I agree with Stephen here, assuming I'm understanding him correctly. When you talk about choices in a UI, you start exponentially increasing the number of paths to do basically the same thing. Exposing a filesystem choice to users really degrades the user experience. Does everyone know what a filesystem is? And if they know, do they know what the options are that we are presenting them? Do they know the pros and the cons between them? Do they really care that much? To me it sounds like the goal here is to advertise other filesystem options in the hopes that we get some drive-by interest by people doing first time installs. 10 years of bug reports tell me that people just don't care about that option. A default is exactly that, a default. We should pick a good default that is well supported across all of the architectures that we care about in Fedora. By exposing a filesystem selection option at install time, we're really saying we have that many defaults. Oh, and we need you to understand them so you can pick one. Most people would probably leave that option alone, which begs the question: why have it at all? It's 2014 and we're still holding on to BTRFS as the solution to all of our filesystem problems. That's fine, but it hasn't happened yet. And as long as that's the story, we should expose something that's actually usable and recommended at install time. I really see no value in offering slightly different filesystem options at install time. If we want something different, it should become the new default. (For clarification, the above is speaking about the automatic partitioning code path, not custom partitioning. Custom will likely always involve more knobs and controls for users, and many filesystem types. But that's ok, custom is for those users.) I am fine with having the custom partitioning be the place to deviate from the defaults... Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: default file system, was: Comparison to Workstation Technical Specification
On Mar 3, 2014, at 6:59 AM, Stephen Gallagher sgall...@redhat.com wrote: To something like: * XFS-LVM (Recommended) * XFS * EXT4-LVM * EXT4 * BTRFS (Experimental) I realize this is not a serious recommendation. However, please no file system Smögåsbord in the guided option. The ice cream truck offers a fantastic vanilla ice cream waffle cone. Please go inside for counter service if you want it in a cup, different flavors, sprinkles, flambé, or with sparklers attached. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fwd: Re: default file system, was: Comparison to Workstation Technical Specification
is, let alone which one would be best to pick. IMHO it really only confuses new people and would not really make them want to stick around long enough to figure out what an fs is all about. The advanced setting/manual partioning is something that tells the new guy there should probably be a little more study or thought put into what they are doing. I believe that would be the place to give someone an option, not default settings on a guided path. Danny Sent from my U.S. Cellular® Smartphone Original message From: Ric Wheeler rwhee...@redhat.com Date:03/03/2014 9:48 AM (GMT-06:00) To: devel@lists.fedoraproject.org Subject: Re: default file system, was: Comparison to Workstation Technical Specification On 03/03/2014 04:40 PM, David Cantrell wrote: On Mon, Mar 03, 2014 at 09:22:53AM -0500, Stephen Gallagher wrote: On 03/03/2014 09:16 AM, Ric Wheeler wrote: On 03/03/2014 04:06 PM, Josef Bacik wrote: On Mon, Mar 3, 2014 at 8:59 AM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/03/2014 08:51 AM, Ric Wheeler wrote: On 03/03/2014 03:43 PM, Stephen Gallagher wrote: So if you were asking me Are we removing btrfs from the install options completely?, the answer is a resounding NO. However, if you're asking Are we removing btrfs from the drop-down of simple-install layouts?, my personal recommendation is yes. I disagree - why would we remove the drop down option? That would make it exceedingly hard and rare for casual users to install and test. Basically, our Fedora btrfs user base would drop to nothing. Making it easy to test is a critical part of taking btrfs up to the next level of stability! It's a matter of user experience, here. By presenting something in the guided drop-down, we are effectively asserting that they are of equal utility and support. This is *not* the reality. Now, if you want to talk about having some sort of click-through for I want to try out some experimental options without going all the way to customizing my layout manually, that (to me) needs to be a different, third path. But listing it directly alongside the default gives a false expectation. Now, this might be as simple as changing the modern drop-down from * EXT4 * BTRFS * XFS [] Use LVM To something like: * XFS-LVM (Recommended) * XFS * EXT4-LVM * EXT4 * BTRFS (Experimental) But even still, Fedora QA is at least ostensibly supposed to test all guided paths and best-effort of custom paths. This is more paths than are strictly necessary, especially considering that we don't expect many people to actually USE the guided paths (in favor of custom and/or kickstart). Ok I was just confused as I haven't done a normal install in a few releases. So you can still get to btrfs going through some new custom layout option but you want to remove the install onto btrfs easy button in the normal guided option? I'm ok with this, I just want to make sure that I/users don't have to jump through icantbelieveitsnotbtr hoops to install onto btrfs. Thanks, Josef I am fine with something like what is proposed by Steve above - let users have the GUI present an option that gives preference to the default without totally hiding other options. To be clear, I don't really like that option at all. I was presenting it to show how it's not a great user experience. That being said, if everyone else (and especially QA) prefers that approach, I'm certainly flexible on the point. I'm really hoping that the design, user experience, anaconda and QA teams will make their opinions on this known. I know full well that this is not my area of expertise. BCCing a few specific individuals to hopefully get their input. I agree with Stephen here, assuming I'm understanding him correctly. When you talk about choices in a UI, you start exponentially increasing the number of paths to do basically the same thing. Exposing a filesystem choice to users really degrades the user experience. Does everyone know what a filesystem is? And if they know, do they know what the options are that we are presenting them? Do they know the pros and the cons between them? Do they really care that much? To me it sounds like the goal here is to advertise other filesystem options in the hopes that we get some drive-by interest by people doing first time installs. 10 years of bug reports tell me that people just don't care about that option. A default is exactly that, a default. We should pick a good default that is well supported across all of the architectures that we care about in Fedora. By exposing a filesystem selection option at install time, we're really saying we have that many defaults. Oh, and we need you to understand them so you can pick one. Most people would probably leave that option alone, which begs the question: why have it at all? It's 2014 and we're still holding on to BTRFS as the solution
Re: default file system, was: Comparison to Workstation Technical Specification
On Mon, 2014-03-03 at 16:16 +0200, Ric Wheeler wrote: I am fine with something like what is proposed by Steve above - let users have the GUI present an option that gives preference to the default without totally hiding other options. You and Josef are sending mixed messages here: btrfs is fine, but just not ready to be the default and don't make it the default, but we still need users to install it so it can get better, so don't take away the option. I don't think that is reasonable - either it is ready to be widely used, ie the default, or it isn't in which case it shouldn't appear in the UI. I'm pretty firmly against filesystem choice in the workstation installer. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 03/03/2014 11:16 PM, Matthias Clasen wrote: On Mon, 2014-03-03 at 16:16 +0200, Ric Wheeler wrote: I am fine with something like what is proposed by Steve above - let users have the GUI present an option that gives preference to the default without totally hiding other options. You and Josef are sending mixed messages here: btrfs is fine, but just not ready to be the default and don't make it the default, but we still need users to install it so it can get better, so don't take away the option. I don't think that is reasonable - either it is ready to be widely used, ie the default, or it isn't in which case it shouldn't appear in the UI. I'm pretty firmly against filesystem choice in the workstation installer. There are many things that are ready to be used but are not the default. Like ext4 for example :) I think it is not reasonable to assume that everything that is ready to use for some users but is not ready to use as the default should be hidden but it is reasonable to hide this in the advanced configuration menu as suggested by others. Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 3/3/14, 3:16 PM, Matthias Clasen wrote: On Mon, 2014-03-03 at 16:16 +0200, Ric Wheeler wrote: I am fine with something like what is proposed by Steve above - let users have the GUI present an option that gives preference to the default without totally hiding other options. You and Josef are sending mixed messages here: btrfs is fine, but just not ready to be the default and don't make it the default, but we still need users to install it so it can get better, so don't take away the option. I don't think that is reasonable - either it is ready to be widely used, ie the default, or it isn't in which case it shouldn't appear in the UI. The combination of those requirements would seem to mean that only the default filesystem may appear in the UI... I'm pretty firmly against filesystem choice in the workstation installer. Ah! I guess that is how you feel. :) We do need _some_ mechanism for willing users to test more cutting-edge code on a real install, or everything besides the default may wither and die, as nothing else can get any real-world exposure... -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 03/03/2014 11:29 PM, Eric Sandeen wrote: On 3/3/14, 3:16 PM, Matthias Clasen wrote: On Mon, 2014-03-03 at 16:16 +0200, Ric Wheeler wrote: I am fine with something like what is proposed by Steve above - let users have the GUI present an option that gives preference to the default without totally hiding other options. You and Josef are sending mixed messages here: btrfs is fine, but just not ready to be the default and don't make it the default, but we still need users to install it so it can get better, so don't take away the option. I don't think that is reasonable - either it is ready to be widely used, ie the default, or it isn't in which case it shouldn't appear in the UI. The combination of those requirements would seem to mean that only the default filesystem may appear in the UI... I'm pretty firmly against filesystem choice in the workstation installer. Ah! I guess that is how you feel. :) We do need _some_ mechanism for willing users to test more cutting-edge code on a real install, or everything besides the default may wither and die, as nothing else can get any real-world exposure... -Eric The nice thing about choice is that - even for users who don't want to test new features - others can. Making it not part of the normal drop down (hiding it in the custom configuration menu) seems to be quite reasonable to me. Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Sat, Mar 1, 2014 at 3:18 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 1, 2014, at 1:19 PM, Jon jdisn...@gmail.com wrote: The inability to shrink or reduce XFS is rather disappointing. I've seen a few sarcastic remarks along the lines of (paraphrased): why would anyone ever want to shrink a volume? In the context of server, and default installs, why is a valid question. People do shrink volumes, and this lack of flexibility is an important consideration I feel was ignored in the Server WG decision. What is the use case for volume shrinking in a server context? Dual boot is a total edge case for servers. In the context of Fedora-ARM, people would regularly shrink ext4 filesystem images to fit on different size storage. We would release an 8GiB image, but the ARM board might only have 4GiB eMMC or somebody has a smaller sdcard (stuff like that). We no longer release Fedora ARM rootfs tarballs, too hard to educate people to do the right thing with ACL's, xattrs, selinux, etc... Anyhow, it's actually a great way to ship a Fedora rootfs... just shrink the filesystem down to the smallest size, and allow the user to simply resize2fs the image into their storage. This would not be possible with XFS for the server variant of Fedora-ARM, and I feel represents a significant challenge to the ARM team. As for the real world examples of shrinking, well drawing upon my experiences in the past at a managed hosting company: * VG consisted of ten 100 GiB san luns, customer asks one be removed, and provisioned to another server. We shrunk the filesystem, and removed the lun per request. Shrinking support significantly reduced the time needed for that maintenance window! Or put another way, shrinking is much faster than formatting and restoring data from tape to achieve smaller sized volumes. * customer over estimated the requirements for one mount (lets say /opt for example), and underestimated the requirements of another (say /var/log for example). This classic example of where customers fail to properly anticipate the storage requirements of their work-flow at the time of install, and they shrink one to grow another. (this might be solved by the thin provisioning idea) * customer wanted to shrink the SAN luns to a smaller size, but was averse to significant down time to restore from tape. ext4 shrinking to the rescue! In the context of HP-UX I've been in the situation to perform online shrinking with database running on the storage mount. The point is that shrinking is an important feature in a server OS!! for me personally, I'm not sure any performance gains are enough to compensate for the lack of flexibility. Considering that LVM has the ability to resize volumes, ext4 pairs very well, Unless you use system-storage-manager, you might refresh the steps required to do an ext4 on LVM resize. I don't think the person who understands how to do that is really the target audience for default installs. I would disagree on the basis that people who do default install probably are the same group of folks who might not plan ahead for their future storage needs, which usually involves growing storage (something XFS is great at doing), and other times involves shrinking. However these are my 2-bit opinions, all I'm say is we advocate for those consumers who make mistakes, and that we please consider recongnize that XFS has less tolerance for when the mistake happens to be provisioning too much storage. and I'm skeptical thin provisioning does enough make-up for the lack of XFS shrinking. It even makes up for ext4 shrinking in two ways. 1. Instead of making an LV smaller than possibly needed, make it the size it probably should be from the start. It only consumes extents from the thinpool as needed. 2. Upon significant file deletion, fstrim returns unused extents back to the thinpool. This is faster, more efficient, and less fragile than file system shrink. Again, the problem is that commands are a bit esoteric, but maybe system-storage-manager can help out with this once it support thin provisioning. Thin provisioning sounds great, but I'm not sure it replaces the ability to shrink in all situations, but it appears to negate many of the situations I've mentioned, but not all. So my question to the Server WG, did anybody consider this aspect of XFS (lack of shrinking) before making the decision? What were the highest reasons for NOT staying with EXT4? I realize the thread has well over 100 emails in it, but it was considered. The simple explanation why XFS was chosen is because it was well vetted by Red Hat storage experts for use as the default in RHEL 7 - and I understand that sgallagh is working on a summary of those reasons, which would apply here as well. I'd say top on the list is XFS is scales linearly as more threads are thrown at it, it's very good at parallelism, and it support project quotas which often obviates the need to
Re: default file system, was: Comparison to Workstation Technical Specification
On 3/3/14, 5:57 PM, Jon wrote: On Sat, Mar 1, 2014 at 3:18 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 1, 2014, at 1:19 PM, Jon jdisn...@gmail.com wrote: The inability to shrink or reduce XFS is rather disappointing. I've seen a few sarcastic remarks along the lines of (paraphrased): why would anyone ever want to shrink a volume? In the context of server, and default installs, why is a valid question. People do shrink volumes, and this lack of flexibility is an important consideration I feel was ignored in the Server WG decision. What is the use case for volume shrinking in a server context? Dual boot is a total edge case for servers. In the context of Fedora-ARM, people would regularly shrink ext4 filesystem images to fit on different size storage. We would release an 8GiB image, but the ARM board might only have 4GiB eMMC or somebody has a smaller sdcard (stuff like that). For what it's worth, this sort of shrinking growing can lead to some pretty pessimal fs layouts. We no longer release Fedora ARM rootfs tarballs, too hard to educate people to do the right thing with ACL's, xattrs, selinux, etc... Anyhow, it's actually a great way to ship a Fedora rootfs... just shrink the filesystem down to the smallest size, and allow the user to simply resize2fs the image into their storage. This would not be possible with XFS for the server variant of Fedora-ARM, and I feel represents a significant challenge to the ARM team. I was never sure why shrinking was particularly required; maybe it's a little harder or slower, but: do an install, see how much space it used, make a new filesystem with 105% of that space (or so) and install onto that. Done and done? OTOH, the shrinkfs dance was a great way to find myriad bugs in resize2fs. ;) Making a tiny xfs FS and then growing it significantly will also lead to pessimal layouts there - we'll end up with many, many very small allocation groups. The shrink/grow thing was clever, but also a bit abusive from a filesystem design point of view. As for the real world examples of shrinking, well drawing upon my experiences in the past at a managed hosting company: * VG consisted of ten 100 GiB san luns, customer asks one be removed, and provisioned to another server. We shrunk the filesystem, and removed the lun per request. Shrinking support significantly reduced the time needed for that maintenance window! Or put another way, shrinking is much faster than formatting and restoring data from tape to achieve smaller sized volumes. * customer over estimated the requirements for one mount (lets say /opt for example), and underestimated the requirements of another (say /var/log for example). This classic example of where customers fail to properly anticipate the storage requirements of their work-flow at the time of install, and they shrink one to grow another. (this might be solved by the thin provisioning idea) * customer wanted to shrink the SAN luns to a smaller size, but was averse to significant down time to restore from tape. ext4 shrinking to the rescue! It's handy at times, but shrinking really scrambles data layouts. If you don't care about performance, it's probably ok. -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
Once upon a time, Eric Sandeen sand...@redhat.com said: The shrink/grow thing was clever, but also a bit abusive from a filesystem design point of view. How does it compare to the suggested alternative, LVM thin provisioning? How well does thinp handle fragmentation; is there a defrag for thinp available (or planned)? -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Sun, 2014-03-02 at 14:27 +, Richard W.M. Jones wrote: On Fri, Feb 28, 2014 at 01:03:38PM -0800, Adam Williamson wrote: What I came up with is this gem: https://fedoraproject.org/wiki/User:Adamwill/Draft_storage_matrix [...] Some of this is susceptible to automation, but some is not, in the sense that it involves the UI, and automated UI testing is a giant PITA. There was a *great* talk at either FOSDEM or DevConf about what OpenSUSE is using for automation of their UIs. It's all open source, easy to create the scripts using a GUI, and you can fiddle around with bits of Javascript to fine tune the tests. Of course, now I cannot find the talk anywhere ... Anyone see / remember this? Don't really need it, we've already looked at SUSE's OpenQA thing. I saw it as soon as they announced it, and I've kept an eye on it since then. About once every two weeks *someone* mails me, another Fedora QA person, or test@ and says hey, have you seen this OpenQA thing!??!?! :P As GUI automated testing systems go, it's not a bad one. But it *does* suffer from the usual problems: mainly fragility. You can go to http://openqa.opensuse.org/results/ and note that the 'unknown' results are trending upwards over time. There are bad, mediocre and good GUI testing approaches out there, as with all things, but *even the good ones* need a lot of care and feeding. And 'susceptible to automation' is all very well, but it requires someone to do the work of automating it. While I'm not volunteering to implement this, wouldn't fuzz testing using kickstarts be fairly easy to implement and automate? You generate directed random kickstart files, run the installer using a script similar to this: https://github.com/libguestfs/libguestfs/blob/master/builder/website/fedora.sh and then see whether the result is a plausible looking guest. (You could use libguestfs to test whether the resultant guest contains files at known locations, for example.) This moves the question of whether kickstart covers every possibility in Anaconda (or vice versa, I suppose). But it has the advantage that it seems like it would be easy to implement something quickly. It doesn't exercise the UI. Yes, you can use something like that to test the underlying partitioning code, and we really should be doing that and it's been on my todo list forever, but it still doesn't exercise the actual UI. Quite a lot of the bugs we hit tend to the classic UI edge case bugs, like when you slide the slider all the way to the end it tries to create a partition that's 1 byte too small, that kind of thing. You can't really test those with a kickstart. You can, I believe, use a kickstart to produce absolutely any *result* you could get from the interactive installer, but you can't exercise all the UI codepaths. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Mon, 2014-03-03 at 18:50 -0800, Adam Williamson wrote: On Sun, 2014-03-02 at 14:27 +, Richard W.M. Jones wrote: On Fri, Feb 28, 2014 at 01:03:38PM -0800, Adam Williamson wrote: What I came up with is this gem: https://fedoraproject.org/wiki/User:Adamwill/Draft_storage_matrix [...] Some of this is susceptible to automation, but some is not, in the sense that it involves the UI, and automated UI testing is a giant PITA. There was a *great* talk at either FOSDEM or DevConf about what OpenSUSE is using for automation of their UIs. It's all open source, easy to create the scripts using a GUI, and you can fiddle around with bits of Javascript to fine tune the tests. Of course, now I cannot find the talk anywhere ... Anyone see / remember this? Don't really need it, we've already looked at SUSE's OpenQA thing. I saw it as soon as they announced it, and I've kept an eye on it since then. About once every two weeks *someone* mails me, another Fedora QA person, or test@ and says hey, have you seen this OpenQA thing!??!?! :P As GUI automated testing systems go, it's not a bad one. But it *does* suffer from the usual problems: mainly fragility. You can go to http://openqa.opensuse.org/results/ and note that the 'unknown' results are trending upwards over time. There are bad, mediocre and good GUI testing approaches out there, as with all things, but *even the good ones* need a lot of care and feeding. BTW, don't get me wrong, this isn't stop energy - if anyone thinks OpenQA is the coolest thing ever and has an immediate urge to go out and set up an OpenQA instance for Fedora and write a bunch of tests and start running them, you know, PLEASE DO. And of course let test@ know and we'll try to help you out with resources. This is definitely a 'something beats nothing' situation. I just want to make sure anyone who wants to do this goes in with an accurate knowledge of the work that's likely to be involved. I also want to explain that the folks we have in QA already who are interested in working on tools are already full-time working on other things, and yes we have considered OpenQA (and various other GUI automation frameworks, and various other possible uses of our time apart from working on Taskotron and the other tools we're working on), and come to the conclusion that the stuff we're working on right now really is the most important stuff to be working on right now. We certainly do welcome anyone who wants to spend some of their spare cycles working on OTHER things, though. :) -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Mar 3, 2014, at 4:57 PM, Jon jdisn...@gmail.com wrote: We no longer release Fedora ARM rootfs tarballs, too hard to educate people to do the right thing with ACL's, xattrs, selinux, etc... Anyhow, it's actually a great way to ship a Fedora rootfs... just shrink the filesystem down to the smallest size, and allow the user to simply resize2fs the image into their storage. Well unfortunately it's not default ready yet, so it's a bit off-topic. But I see your example as a particularly good use case for several features including btrfs send to a file (restored with btrfs receive onto a new file system of whatever size); and btrfs seed device. This would not be possible with XFS for the server variant of Fedora-ARM, and I feel represents a significant challenge to the ARM team. I'm a bit lost, but I think this is important to understand. Does the Server product anaconda default somehow affect the armv7hl raw.xz images you release? Is there a way to decouple this? Because Fedora ARM doesn't really use anaconda at all, do you? If the anaconda default fs somehow binds your images to using the same thing, does it make sense to consider making XFS the default also contingent on using lvmthinp? Thin provisioning sounds great, but I'm not sure it replaces the ability to shrink in all situations, but it appears to negate many of the situations I've mentioned, but not all. For example? I would imagine people turning their ARM dev board into a home NAS or some similar storage kit, and the linear scale-up of XFS is really appealing. ARM gluster cluster :-) Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Mon, 2014-03-03 at 08:59 -0500, Stephen Gallagher wrote: Now, if you want to talk about having some sort of click-through for I want to try out some experimental options without going all the way to customizing my layout manually, that (to me) needs to be a different, third path. But listing it directly alongside the default gives a false expectation. Custom partitioning actually already provides this path. It would probably be helpful for everyone following this debate to grab a VM and do a few test installs of a recent F21 nightly, so everyone's clear on the UI we're actually debating. When you go into custom partitioning in F21, there's a create partitions for me option (as there was before), and there's now also the 'filesystem type' dropdown box for that choice. So if you just want to get a 'default' btrfs layout, you can go into custom partitioning, change the dropdown to btrfs, hit 'create partitions for me', and you're done (assuming you had some free space available). -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 3/3/14, 7:34 PM, Chris Adams wrote: Once upon a time, Eric Sandeen sand...@redhat.com said: The shrink/grow thing was clever, but also a bit abusive from a filesystem design point of view. How does it compare to the suggested alternative, LVM thin provisioning? How well does thinp handle fragmentation; is there a defrag for thinp available (or planned)? Well, I meant that it was clever for the minimal root fs distribution business. But I think you're right, fragmentation on thinp is something that is still under investigation. -Eric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 03/02/2014 10:55 PM, Chris Murphy wrote: On Mar 2, 2014, at 9:35 PM, Nathanael Noblet nathan...@gnat.ca wrote: On 03/01/2014 04:57 PM, Chris Murphy wrote: The servers were rented with a Fedora produced default/automatic/guided partitioning layout? If not, your example is out of scope. We are only talking about this context specifically, not arbitrary examples for shrinking a file system. The Fedora automatic/guided partition layout is a rootfs of 50GB, and any significant additional space goes to a separate /home. So you're saying you'd shrink a 50GB rootfs for encrypted data, rather than blow away the /home LV, make a new LV, encrypt it, then format it? They were CentOS 6 machines. So perhaps the defaults are different however this is something that happened to me and not being able to shrink a fs would have been problematic / costly for me. Granted the default there was /boot / and swap so I had a 900G / and nothing else thus the shrinking of the / fs. So I suppose that if the servers were fedora and had a /home LV this particular situation wouldn't have been an issue. I just wanted to point out that shrinking a partition is a valid use case is all. In our current default fedora layout I could still accomplish what I needed. But shrinking a fs is a valid use case… Fair enough, and I'm not suggesting shrink is invalid for that matter. I merely want to understand the actual requirement because there may be better ways to address it. Given the XFS shrinking issue it might even be nice to not allocate ALL storage, create /, swap and /home without taking up all storage and then let people enlarge what they need… It's an interesting suggestion. But does this really apply to the target audience of users who are a.) using a GUI installer, and b.) choosing to use an automatic/guided partitioning layout? Is that sort of user likely to jump into a resize operation from the command line post-install? Why wouldn't they just use Manual Partitioning? What you suggest might seem plausible for Server. But I don't think that's a good idea for Workstation, to burden the user with an incomplete partition layout that (silently) proposes they complete or customize it post-install. Yeah, sorry my suggestion wasn't a blanket statement - in fact I wasn't even thinking in terms of Server vs Workstations. For *sure* for the Workstation product where one is using the GUI and accepting defaults using all available space makes sense. Again I wasn't even thinking of that. Just that some defaults have implications especially if I'm not the one doing the install. If some datacenter just fires off an install or uses some image from the default server install I'm in the same unshrinkable fs boat regardless of how I would have done the install myself. Sometimes we assume the defaults are used by 'naive' users using a GUI where they could just as easily be used by massive organizations with thousands of servers with highly trained staff because well it doesn't matter to them. default is default... -- Nathanael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 1 March 2014 21:37, Orion Poplawski or...@cora.nwra.com wrote: On 03/01/2014 02:30 PM, Ian Malone wrote: On 1 March 2014 18:57, Simo Sorce s...@redhat.com wrote: On Sat, 2014-03-01 at 12:04 +, Ian Malone wrote: On 28 February 2014 20:45, Adam Williamson awill...@redhat.com wrote: On Thu, 2014-02-27 at 23:16 -0700, Chris Murphy wrote: As you say they are 'plain' filesystems. Though I now regret not sending my small datapoint in before the Server WG decision. That's that a while ago, after using XFS for a long time we started putting new filesystems onto ext4 and in the past month we moved probably our largest remaining dataset (1.1TB) from XFS to ext4, the main reason has been flexibility with resizing. Particularly the XFS 32bit inode ceiling, (inode64 not working well with NFS). As far as I know inode64 is not really a problem on NFS anymore, which is why I did not raise this as an issue at all (I use NFS and I have a 6TB XFS filesystem with inode64). Unless you have legacy systems that must talk to it. Can we get some definition of legacy here? kernel/nfs-utils versions? I'd have to check what I can share. If it helps: not current RHEL or recent Fedora, until recently some that were over five years old. Also this comment in the XFS FAQ: Beware that some old programs might have problems reading 64bit inodes which seems to be related to stat vs stat64, there are some old programs that might require us to modify. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
Chris Murphy li...@colorremedies.com writes: Okay, I'll bite. Why not rootfs on raid6? It's pathological. Sick? Non-functional? Unlucky? There are too many simpler, faster, more resilient options considering rootfs at most isn't bigger than the average SSD: Two or three SSDs + n-way mirroring. RAID 10. Or RAID 1 + linear + XFS for deterministic workloads. Doesn't the size argument assume that some drives are set aside for rootfs only? Otherwise, it's reasonable to apply the same raid5/6 trade-offs to rootfs as to the other data on a shared pool of drives. - FChE -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Fri, Feb 28, 2014 at 01:03:38PM -0800, Adam Williamson wrote: What I came up with is this gem: https://fedoraproject.org/wiki/User:Adamwill/Draft_storage_matrix [...] Some of this is susceptible to automation, but some is not, in the sense that it involves the UI, and automated UI testing is a giant PITA. There was a *great* talk at either FOSDEM or DevConf about what OpenSUSE is using for automation of their UIs. It's all open source, easy to create the scripts using a GUI, and you can fiddle around with bits of Javascript to fine tune the tests. Of course, now I cannot find the talk anywhere ... Anyone see / remember this? And 'susceptible to automation' is all very well, but it requires someone to do the work of automating it. While I'm not volunteering to implement this, wouldn't fuzz testing using kickstarts be fairly easy to implement and automate? You generate directed random kickstart files, run the installer using a script similar to this: https://github.com/libguestfs/libguestfs/blob/master/builder/website/fedora.sh and then see whether the result is a plausible looking guest. (You could use libguestfs to test whether the resultant guest contains files at known locations, for example.) This moves the question of whether kickstart covers every possibility in Anaconda (or vice versa, I suppose). But it has the advantage that it seems like it would be easy to implement something quickly. 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 02/28/2014 06:20 AM, Chris Murphy wrote: On Feb 26, 2014, at 12:53 PM, Michael Cronenworth m...@cchtml.com wrote: Chris Murphy wrote: by default we put ext4 on LVM The tool works in this use-case unless something has broken it recently. It can be done, the convert tool should work, and Btrfs should work on any device mapper instance. However… In the context of the default ext4+LVM layout the conversion still means separate /boot, /, and /home file systems. A major benefit of the Btrfs layout is these are subvolumes, which instead draw space from one volume pool. And that's lost with a conversion strategy. It also means going from a Fedora standard layout to a distinctly non-standard one because our Btrfs layout isn't like the result you'd get from what you're talking about. Chris Murphy That is not much different than what happens with device mapper - the new device mapper has a shared exception store that can be used to share physical space across multiple real file systems. Note that the real file systems can be thinly provisioned or fully provisioned, but if you start full, you will need to add space to grow (unless you shrink something). btrfs subvolumes are kind of hackish to be honest, they are in many ways like real file systems. ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 02/28/2014 07:56 AM, James Wilson Harshaw IV wrote: Yet what was the main point that it wasn't ready yet? My point is we should choose the best solution, even if it takes a little more work to get it up and running. I want to know what it will take to make sure btrfs is good to go as default and then see if the end result will out weigh the effort put in. -James Having more people jump in to help on btrfs is always welcome - it should be a choice for users, even if not the default choice. Also note that it is not just an issue of ready or not, it has some specific workloads that cause even a rock solid instance of btrfs heart-ache. People often get confused with the arrival of a new choice and obsolescence of the old technologies. That is definitely not the case with XFS or ext4, both have a ton of active developers and lots of new features. On top of the many new device mapper targets, we have some very compelling features for the mature stack :) Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 03/01/2014 08:51 AM, Chris Adams wrote: Once upon a time, Chris Murphyli...@colorremedies.com said: There are good reasons to use XFS by default for Server. Are they listed somewhere? XFS has many advantages: * best performance for most workloads (especially with high speed storage and larger number of cores) * tends to be less CPU intensive (better optimizations around lock contention, etc) * most robust at large scale - has been run at hundred plus TB sizes for many years (and today's storage is getting way bigger, 16TB is about half a shelf of drives) * XFS is the most common file system in multiple key upstream communities: most common base for ceph, gluster and openstack more broadly * pioneered most of the techniques now in ext4 for performance (like delayed allocation) That said, ext4 has not been standing still: * it has made major advances as well in the past few years in closing in on XFS features * goes toe to toe with XFS in many workloads, especially on smaller storage sizes. It will tend to be faster than XFS with some specific workloads (like single threaded, metadata intensive workloads) * commonly used file system in major sites systems (google, android, RHEL6) I think that having XFS as the default for servers and ext4 as a default for workstations is reasonable. As part of the group that works on both, it won't make our lives any crazier :) Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 03/01/2014 10:19 PM, Jon wrote: The inability to shrink or reduce XFS is rather disappointing. I've seen a few sarcastic remarks along the lines of (paraphrased): why would anyone ever want to shrink a volume? If you use a dm-thin target with a shared storage pool (even if the file system is fully backed, i.e. not actually thin), you will get the best case for shrinking. You can set up say a 1TB file system and only use space that is consumed by the actual users of that file system. When users delete a file, that freed space is returned to the pool and can be reassigned to other file systems. Also keep in mind that shrinking - on any file system - often really messes up your data allocation and can have bad performance impacts (on ext3 or ext4). You can always do better when you tar up your old data, make a new, smaller file system and then restore it. That said, it is not impossible to add shrink to XFS, we just need to bubble that up the priority queue of things to do. thanks! Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 03/02/2014 01:17 PM, Ian Malone wrote: Can we get some definition of legacy here? kernel/nfs-utils versions? I'd have to check what I can share. If it helps: not current RHEL or recent Fedora, until recently some that were over five years old. Also this comment in the XFS FAQ: Beware that some old programs might have problems reading 64bit inodes which seems to be related to stat vs stat64, there are some old programs that might require us to modify. Just to be clear, defaults are only important when you install. I don't think anyone is suggesting compiling out the ext4 code from the kernel so this should be of zero impact to someone running a file year old system who wants to upgrade to something modern. If you need to stay on that five year old system and not upgrade, I am not sure I understand why it would be a reasonable example. As other people have mentioned, there are ways to create an XFS instance that does not use 64 bit inodes (but that is *not* a sane default since the problems you refer to are not common with modern apps). Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 02/27/2014 02:43 PM, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/27/2014 12:18 AM, Chris Murphy wrote: On Feb 26, 2014, at 5:33 PM, Josef Bacik jo...@toxicpanda.com mailto:jo...@toxicpanda.com wrote: Just popping in here to say that btrfs is not ready to be default in Fedora yet. Optional is fine but not default. OK good, that's definitive. Thanks Josef. So my thought is Workstation WG choices: parity with Server WG, whatever they choose; or plain ext4; or keep things the same with LVM + ext4. And on the question of an alternate choice (what currently appears in the Automatic/Guided path's Partition Scheme pop-up menu) the WG's might consider this too, even whether an alternate is desired. Because from a my personal QA perspective, I'd like to see the two products agree on either the default or an alternate so we don't have four total possible paths combined, which today means 100 testable outcomes. One or two paths is ideal; three might be OK. Four is like… chickens with no heads, running. Speaking for myself, I have a slight preference on using XFS-on-LVM for the default filesystem in the Fedora Server, but if both of the other Products would prefer ext4-on-LVM, I suppose we could negotiate. If we can arrange things so we only have a single installer with different install targets (at least for the net install), I'd consider the reduction in testing effort at least worthy of argument at being more valuable than the filesystem choice. Question for the cloud folks: I realize that XFS is a difficult pill to swallow for /boot, due to your use of syslinux instead of GRUB2. If the Server and Workstation groups decide to settle on both using XFS-on-LVM for the main partitions, we could *probably* also compromise on using ext4 for just /boot. Directed more broadly at all three products: Formal proposal (for discussion): All three products agree to use ext4 for /boot and XFS-on-LVM for all other partitions in the guided mode. All is fair game in the custom mode. Also, for the sake of everyone's sanity, as we discuss this specific proposal, let's hold the conversation to devel@lists.fedoraproject.org (making this the last cross-posted message in the thread). I have a strong preference for using XFS on LVM as the default for any server install based on the fact that it is the common server configuration in a huge number of real servers in production :) Ric -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Mar 2, 2014, at 6:17 AM, Frank Ch. Eigler f...@redhat.com wrote: Chris Murphy li...@colorremedies.com writes: Okay, I'll bite. Why not rootfs on raid6? It's pathological. Sick? Non-functional? Unlucky? Compulsive as in doing something merely because it can be done, but also not well-behaved, and counter-intuitive. There are better ways to achieve the desired results. There are too many simpler, faster, more resilient options considering rootfs at most isn't bigger than the average SSD: Two or three SSDs + n-way mirroring. RAID 10. Or RAID 1 + linear + XFS for deterministic workloads. Doesn't the size argument assume that some drives are set aside for rootfs only? Otherwise, it's reasonable to apply the same raid5/6 trade-offs to rootfs as to the other data on a shared pool of drives. Is it reasonable to expose untested features in the UI? RAID 1 and RAID 10 are probably reasonably well tested because they meet the requirements (and then some) for many use cases. We have test cases for them. There are no RAID 4 or RAID 6 test cases, so should users be permitted to choose untested options? Just because a test case exists, doesn't guarantee that it'll be tested, let alone thoroughly tested or that failure of a test case constitutes a release blocker. It isn't possible for users to make an informed decision the way QA does things now, because the user has no way of knowing the relative testing Manual Partitioning features and outcomes get. And QA has no way of making that more transparent at the moment. This is what's meant by custom partitioning testing being best effort. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
Am 02.03.2014 19:38, schrieb Chris Murphy: Is it reasonable to expose untested features in the UI? RAID 1 and RAID 10 are probably reasonably well tested because they meet the requirements (and then some) for many use cases. We have test cases for them. There are no RAID 4 or RAID 6 test cases, so should users be permitted to choose untested options? wrong direction - if we are talk about Fedora.next the main question is why are they not tested and not don't use them because we don't test as said: if Fedora wants to compete with commercial solutions where nobody spends a second to consider if RAID5/RAID6 is supported for whatever because it is unconditional clear you argue the wrong direction there are people using RAID6 for *anything* because it is *common knowledge* that after one disk fails the chance due rebuild have another one fails is way too high and RAID10 does *not* help here if it comes to important data the problem of RAID10 is that the right one second disks needs to fail and you can hardly chose that - in case of important data you must not need to hope, you need safety signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 03/01/2014 04:57 PM, Chris Murphy wrote: The servers were rented with a Fedora produced default/automatic/guided partitioning layout? If not, your example is out of scope. We are only talking about this context specifically, not arbitrary examples for shrinking a file system. The Fedora automatic/guided partition layout is a rootfs of 50GB, and any significant additional space goes to a separate /home. So you're saying you'd shrink a 50GB rootfs for encrypted data, rather than blow away the /home LV, make a new LV, encrypt it, then format it? They were CentOS 6 machines. So perhaps the defaults are different however this is something that happened to me and not being able to shrink a fs would have been problematic / costly for me. Granted the default there was /boot / and swap so I had a 900G / and nothing else thus the shrinking of the / fs. So I suppose that if the servers were fedora and had a /home LV this particular situation wouldn't have been an issue. I just wanted to point out that shrinking a partition is a valid use case is all. In our current default fedora layout I could still accomplish what I needed. But shrinking a fs is a valid use case... Given the XFS shrinking issue it might even be nice to not allocate ALL storage, create /, swap and /home without taking up all storage and then let people enlarge what they need... -- Nathanael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Mar 2, 2014, at 9:35 PM, Nathanael Noblet nathan...@gnat.ca wrote: On 03/01/2014 04:57 PM, Chris Murphy wrote: The servers were rented with a Fedora produced default/automatic/guided partitioning layout? If not, your example is out of scope. We are only talking about this context specifically, not arbitrary examples for shrinking a file system. The Fedora automatic/guided partition layout is a rootfs of 50GB, and any significant additional space goes to a separate /home. So you're saying you'd shrink a 50GB rootfs for encrypted data, rather than blow away the /home LV, make a new LV, encrypt it, then format it? They were CentOS 6 machines. So perhaps the defaults are different however this is something that happened to me and not being able to shrink a fs would have been problematic / costly for me. Granted the default there was /boot / and swap so I had a 900G / and nothing else thus the shrinking of the / fs. So I suppose that if the servers were fedora and had a /home LV this particular situation wouldn't have been an issue. I just wanted to point out that shrinking a partition is a valid use case is all. In our current default fedora layout I could still accomplish what I needed. But shrinking a fs is a valid use case… Fair enough, and I'm not suggesting shrink is invalid for that matter. I merely want to understand the actual requirement because there may be better ways to address it. Given the XFS shrinking issue it might even be nice to not allocate ALL storage, create /, swap and /home without taking up all storage and then let people enlarge what they need… It's an interesting suggestion. But does this really apply to the target audience of users who are a.) using a GUI installer, and b.) choosing to use an automatic/guided partitioning layout? Is that sort of user likely to jump into a resize operation from the command line post-install? Why wouldn't they just use Manual Partitioning? What you suggest might seem plausible for Server. But I don't think that's a good idea for Workstation, to burden the user with an incomplete partition layout that (silently) proposes they complete or customize it post-install. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 28 February 2014 20:45, Adam Williamson awill...@redhat.com wrote: On Thu, 2014-02-27 at 23:16 -0700, Chris Murphy wrote: On Feb 27, 2014, at 11:07 PM, James Wilson Harshaw IV jwhars...@gmail.com wrote: I apologize, I guess I did not get the whole background out of it. What filesystems are we considering? It's XFS vs ext4 and Server WG has agreed on XFS on LVM. As a server WG member I voted +1 on XFS as I have no particular objection to XFS as a filesystem, but I do think it seems a bit sub-optimal for us to wind up with server and desktop having defaults that are very similar but slightly different, for no apparently great reason. ext4 and xfs are basically what I refer to as 'plain' filesystems (i.e. not all souped-up btrfs/zfs stuff), they're stable, mature, and generally good-enough for just about all cases. Is xfs really so much better for servers, and ext4 so much better for desktops, that it's worth the extra development/maintenance to allow Desktop to use ext4 and Server to use xfs? Basically, what I'm saying is that if Desktop would be OK with using xfs-on-LVM as default with all choices demoted to custom partitioning (no dropdown), as Server has currently agreed on, that'd be great. Or if we could otherwise achieve agreement on something. As you say they are 'plain' filesystems. Though I now regret not sending my small datapoint in before the Server WG decision. That's that a while ago, after using XFS for a long time we started putting new filesystems onto ext4 and in the past month we moved probably our largest remaining dataset (1.1TB) from XFS to ext4, the main reason has been flexibility with resizing. Particularly the XFS 32bit inode ceiling, (inode64 not working well with NFS). 1TB doesn't sound very big. These are imaging datasets in a research environment, files going from small text to images at tens of MB (some bigger, but not the dominant type). Projects usually get their own FS (for a variety of reasons including backup, audit and budgeting reasons). And often it's not known how large a project will eventually be, so filesystems get extended as appropriate. With XFS we have to take care to avoid the 32bit inode ceiling, and most recently found a filesystem that refused to take any more files for some other reason, even after creating a new clean copy. We didn't get to the bottom of that, and moved the data to ext4. Which is not to say XFS is a bad decision, there's plenty of people using it for other tasks, but I looked through the Server WG meeting and couldn't see mention of the for/against arguments. If my ramble above demonstrates anything it's not really about XFS, it's that server admins have reasons for choosing an FS and the scope to look at and change to alternatives. Default FS on the Server is not actually a massive impact, LVM is a different decision and makes sense there. LVM on a workstation though, well, you can make it the default, but a couple of releases ago I started turning it off and will continue doing so. It adds an extra level of complication to management which doesn't gain you anything on a workstation. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 03/01/2014 05:04 AM, Ian Malone wrote: As you say they are 'plain' filesystems. Though I now regret not sending my small datapoint in before the Server WG decision. That's that a while ago, after using XFS for a long time we started putting new filesystems onto ext4 and in the past month we moved probably our largest remaining dataset (1.1TB) from XFS to ext4, the main reason has been flexibility with resizing. Particularly the XFS 32bit inode ceiling, (inode64 not working well with NFS). Could you speak more to the inode64/NFS issue? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
Am 01.03.2014 16:42, schrieb Orion Poplawski: On 03/01/2014 05:04 AM, Ian Malone wrote: As you say they are 'plain' filesystems. Though I now regret not sending my small datapoint in before the Server WG decision. That's that a while ago, after using XFS for a long time we started putting new filesystems onto ext4 and in the past month we moved probably our largest remaining dataset (1.1TB) from XFS to ext4, the main reason has been flexibility with resizing. Particularly the XFS 32bit inode ceiling, (inode64 not working well with NFS). Could you speak more to the inode64/NFS issue? https://www.google.com/search?q=inode64+nfs signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Sat, 2014-03-01 at 12:04 +, Ian Malone wrote: On 28 February 2014 20:45, Adam Williamson awill...@redhat.com wrote: On Thu, 2014-02-27 at 23:16 -0700, Chris Murphy wrote: On Feb 27, 2014, at 11:07 PM, James Wilson Harshaw IV jwhars...@gmail.com wrote: I apologize, I guess I did not get the whole background out of it. What filesystems are we considering? It's XFS vs ext4 and Server WG has agreed on XFS on LVM. As a server WG member I voted +1 on XFS as I have no particular objection to XFS as a filesystem, but I do think it seems a bit sub-optimal for us to wind up with server and desktop having defaults that are very similar but slightly different, for no apparently great reason. ext4 and xfs are basically what I refer to as 'plain' filesystems (i.e. not all souped-up btrfs/zfs stuff), they're stable, mature, and generally good-enough for just about all cases. Is xfs really so much better for servers, and ext4 so much better for desktops, that it's worth the extra development/maintenance to allow Desktop to use ext4 and Server to use xfs? Basically, what I'm saying is that if Desktop would be OK with using xfs-on-LVM as default with all choices demoted to custom partitioning (no dropdown), as Server has currently agreed on, that'd be great. Or if we could otherwise achieve agreement on something. As you say they are 'plain' filesystems. Though I now regret not sending my small datapoint in before the Server WG decision. That's that a while ago, after using XFS for a long time we started putting new filesystems onto ext4 and in the past month we moved probably our largest remaining dataset (1.1TB) from XFS to ext4, the main reason has been flexibility with resizing. Particularly the XFS 32bit inode ceiling, (inode64 not working well with NFS). 1TB doesn't sound very big. These are imaging datasets in a research environment, files going from small text to images at tens of MB (some bigger, but not the dominant type). Projects usually get their own FS (for a variety of reasons including backup, audit and budgeting reasons). And often it's not known how large a project will eventually be, so filesystems get extended as appropriate. With XFS we have to take care to avoid the 32bit inode ceiling, and most recently found a filesystem that refused to take any more files for some other reason, even after creating a new clean copy. We didn't get to the bottom of that, and moved the data to ext4. Which is not to say XFS is a bad decision, there's plenty of people using it for other tasks, but I looked through the Server WG meeting and couldn't see mention of the for/against arguments. If my ramble above demonstrates anything it's not really about XFS, it's that server admins have reasons for choosing an FS and the scope to look at and change to alternatives. Default FS on the Server is not actually a massive impact, LVM is a different decision and makes sense there. LVM on a workstation though, well, you can make it the default, but a couple of releases ago I started turning it off and will continue doing so. It adds an extra level of complication to management which doesn't gain you anything on a workstation. As far as I know inode64 is not really a problem on NFS anymore, which is why I did not raise this as an issue at all (I use NFS and I have a 6TB XFS filesystem with inode64). Simo. -- Simo Sorce * Red Hat, Inc * New York -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Mar 1, 2014, at 11:57 AM, Simo Sorce s...@redhat.com wrote: As far as I know inode64 is not really a problem on NFS anymore, which is why I did not raise this as an issue at all (I use NFS and I have a 6TB XFS filesystem with inode64). What I'm not certain of, is if the fix was entirely on the server such that old NFSv3 client don't run into this problem with relatively recent Fedoras? Or does it also require updated clients? Since the work around is kinda esoteric, we should make sure our target users (guided partitioning) don't run into it even if their clients are running older clients (within reason). With 5TB drives, and guided install permitting the selection of multiple devices, it's easy to create decently large storage Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
The inability to shrink or reduce XFS is rather disappointing. I've seen a few sarcastic remarks along the lines of (paraphrased): why would anyone ever want to shrink a volume? People do shrink volumes, and this lack of flexibility is an important consideration I feel was ignored in the Server WG decision. for me personally, I'm not sure any performance gains are enough to compensate for the lack of flexibility. Considering that LVM has the ability to resize volumes, ext4 pairs very well, and I'm skeptical thin provisioning does enough make-up for the lack of XFS shrinking. I've seen a number of presentations on XFS and I'm personally very happy about the raw gains in performance and resilience. So in that respect XFS is a good choice for the Server WG. So my question to the Server WG, did anybody consider this aspect of XFS (lack of shrinking) before making the decision? What were the highest reasons for NOT staying with EXT4? Thanks, -Jon Disnard fas: parasense irc: masta -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Fri, Feb 28, 2014 at 11:29:30PM -0700, Chris Murphy wrote: - There needs to be a mandate to remove features from custom partitioning that quite frankly don't make sense like rootfs on raid4, raid5 or raid6. OK maybe raid5. But not raid 4 or raid 6. There are other Okay, I'll bite. Why not rootfs on raid6? -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Mar 1, 2014, at 1:19 PM, Jon jdisn...@gmail.com wrote: The inability to shrink or reduce XFS is rather disappointing. I've seen a few sarcastic remarks along the lines of (paraphrased): why would anyone ever want to shrink a volume? In the context of server, and default installs, why is a valid question. People do shrink volumes, and this lack of flexibility is an important consideration I feel was ignored in the Server WG decision. What is the use case for volume shrinking in a server context? Dual boot is a total edge case for servers. for me personally, I'm not sure any performance gains are enough to compensate for the lack of flexibility. Considering that LVM has the ability to resize volumes, ext4 pairs very well, Unless you use system-storage-manager, you might refresh the steps required to do an ext4 on LVM resize. I don't think the person who understands how to do that is really the target audience for default installs. and I'm skeptical thin provisioning does enough make-up for the lack of XFS shrinking. It even makes up for ext4 shrinking in two ways. 1. Instead of making an LV smaller than possibly needed, make it the size it probably should be from the start. It only consumes extents from the thinpool as needed. 2. Upon significant file deletion, fstrim returns unused extents back to the thinpool. This is faster, more efficient, and less fragile than file system shrink. Again, the problem is that commands are a bit esoteric, but maybe system-storage-manager can help out with this once it support thin provisioning. So my question to the Server WG, did anybody consider this aspect of XFS (lack of shrinking) before making the decision? What were the highest reasons for NOT staying with EXT4? I realize the thread has well over 100 emails in it, but it was considered. The simple explanation why XFS was chosen is because it was well vetted by Red Hat storage experts for use as the default in RHEL 7 - and I understand that sgallagh is working on a summary of those reasons, which would apply here as well. I'd say top on the list is XFS is scales linearly as more threads are thrown at it, it's very good at parallelism, and it support project quotas which often obviates the need to create separate file systems as a means of constraining storage usage rather than doing it only by user or group. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 1 March 2014 18:57, Simo Sorce s...@redhat.com wrote: On Sat, 2014-03-01 at 12:04 +, Ian Malone wrote: On 28 February 2014 20:45, Adam Williamson awill...@redhat.com wrote: On Thu, 2014-02-27 at 23:16 -0700, Chris Murphy wrote: As you say they are 'plain' filesystems. Though I now regret not sending my small datapoint in before the Server WG decision. That's that a while ago, after using XFS for a long time we started putting new filesystems onto ext4 and in the past month we moved probably our largest remaining dataset (1.1TB) from XFS to ext4, the main reason has been flexibility with resizing. Particularly the XFS 32bit inode ceiling, (inode64 not working well with NFS). 1TB doesn't sound very big. These are imaging datasets in a research environment, files going from small text to images at tens of MB (some bigger, but not the dominant type). Projects usually get their own FS (for a variety of reasons including backup, audit and budgeting reasons). And often it's not known how large a project will eventually be, so filesystems get extended as appropriate. With XFS we have to take care to avoid the 32bit inode ceiling, and most recently found a filesystem that refused to take any more files for some other reason, even after creating a new clean copy. We didn't get to the bottom of that, and moved the data to ext4. As far as I know inode64 is not really a problem on NFS anymore, which is why I did not raise this as an issue at all (I use NFS and I have a 6TB XFS filesystem with inode64). Unless you have legacy systems that must talk to it. And the other problem I mentioned, which we didn't solve, but didn't seem to be inode64 (copy data onto a new fs of sufficient size and it should be difficult to hit the 32bit limit). That machine is running an older kernel, I'm not saying there's a particular problem with going with XFS for server, what I should have said was it's probably the wrong way round to have the server FS decision dictate the desktop one, which seems to be what's going to happen. -- imalone http://ibmalone.blogspot.co.uk -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 03/01/2014 02:30 PM, Ian Malone wrote: On 1 March 2014 18:57, Simo Sorce s...@redhat.com wrote: On Sat, 2014-03-01 at 12:04 +, Ian Malone wrote: On 28 February 2014 20:45, Adam Williamson awill...@redhat.com wrote: On Thu, 2014-02-27 at 23:16 -0700, Chris Murphy wrote: As you say they are 'plain' filesystems. Though I now regret not sending my small datapoint in before the Server WG decision. That's that a while ago, after using XFS for a long time we started putting new filesystems onto ext4 and in the past month we moved probably our largest remaining dataset (1.1TB) from XFS to ext4, the main reason has been flexibility with resizing. Particularly the XFS 32bit inode ceiling, (inode64 not working well with NFS). As far as I know inode64 is not really a problem on NFS anymore, which is why I did not raise this as an issue at all (I use NFS and I have a 6TB XFS filesystem with inode64). Unless you have legacy systems that must talk to it. Can we get some definition of legacy here? kernel/nfs-utils versions? -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 03/01/2014 02:18 PM, Chris Murphy wrote: On Mar 1, 2014, at 1:19 PM, Jon jdisn...@gmail.com wrote: The inability to shrink or reduce XFS is rather disappointing. I've seen a few sarcastic remarks along the lines of (paraphrased): why would anyone ever want to shrink a volume? In the context of server, and default installs, why is a valid question. People do shrink volumes, and this lack of flexibility is an important consideration I feel was ignored in the Server WG decision. What is the use case for volume shrinking in a server context? Dual boot is a total edge case for servers. Recently I had a client who required that some data be on an encrypted partition. The servers were rented from a datacenter instead of being cloud based etc. As such you don't have access to the kickstart used to initialize and install the OS. So we had to shrink the rootfs to make room for a new lvm partition for the data. I've had to do that a handful of times for various reasons but the above is the most recent. -- Nathanael -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
People do shrink volumes, and this lack of flexibility is an important consideration I feel was ignored in the Server WG decision. What is the use case for volume shrinking in a server context? Dual boot is a total edge case for servers. I shrink ext4 filesystems on servers pretty frequently. Most recently because: *) Received bad information from an end user which required changing several LVs/FSs. *) An oops situation where a filesystem was incorrectly increased by an extra order of magnitude *) Unexpected (e.g. emergency) growth of an application which required increasing a filesystem and shrinking another (lesser) used filesystem. Yes in all three aforementioned cases we had to unmount the ext4 filesystem in order to shrink it, however, we would _not_ have been able to do this with xfs. On a semi related note: I grow/shrink JFS2 filesystems (on AIX) all the time. It would be great if ext4 had online shrink. -Jacob -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 27.02.2014 22:06, Matthew Miller wrote: On Thu, Feb 27, 2014 at 04:03:06PM -0500, Josh Boyer wrote: Or, as an alternative, XFS support could be added to u-boot and/or syslinux. Never eliminate the possibility of actually writing code to fix problems. All it takes is someone willing to do work ;). Right, and as I understand it, there actually _is_ some level of support, and there was a GSoC project related to it a couple of years ago. EXTLINUX: Initial XFS filesystem support - 2012-07-21 http://git.kernel.org/cgit/boot/syslinux/syslinux.git/commit/extlinux?id=a126f17f663c438ef264a459fa130951dbac780d EXTLINUX: Add sanity check for XFS filesystems - 2012-07-29 http://git.kernel.org/cgit/boot/syslinux/syslinux.git/commit/extlinux?id=7997877811d9ce99efed65604bba2bae91332c79 Merge branch 'xfs-for-hpa' of git://zytor.com/users/pcacjr/syslinux into merge/elflink/xfs - 2012-11-27 http://git.kernel.org/cgit/boot/syslinux/syslinux.git/commit/extlinux?id=f3cac0e6203c532efc97a6ae8955fc4b79a2b373 extlinux: Also install ldlinux.c32 file on XFS - 2013-01-22 http://git.kernel.org/cgit/boot/syslinux/syslinux.git/commit/extlinux?id=129a5845aec4d6c750c4bddd936f315fb441d2fa Maybe the problem is in the version that is referred, syslinux-4.05-7.fc20 ... 2013-08-05 ... http://koji.fedoraproject.org/koji/packageinfo?packageID=429 syslinux-4.05-5.el7.x86_64.rpm ftp://ftp.redhat.com/pub/redhat/rhel/beta/7/x86_64/os/Packages/ in contrast to these, syslinux-5.10.tar.xz04-Jun-2013 ... syslinux-6.02.tar.xz13-Oct-2013 ... https://www.kernel.org/pub/linux/utils/boot/syslinux/ poma http://www.syslinux.org/wiki/index.php/The_Syslinux_Project ... 2013-10-13 : Syslinux 6.02 released. ... 2013-06-04 : Syslinux 5.10 released. ... 2011-12-09 : Syslinux 4.05 released. ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
In a side note, there have been *some* attempts at adding shrink compatability to xfs, but none of them seem to developed or even complete. Shrinking in my experience is extremely important. Having unexpected growth in the / partition with no ability to make room for it can be a major issue as this has happened to one of my servers and it was not a pretty situation. On Mar 1, 2014 4:43 PM, Jacob Yundt jyu...@gmail.com wrote: People do shrink volumes, and this lack of flexibility is an important consideration I feel was ignored in the Server WG decision. What is the use case for volume shrinking in a server context? Dual boot is a total edge case for servers. I shrink ext4 filesystems on servers pretty frequently. Most recently because: *) Received bad information from an end user which required changing several LVs/FSs. *) An oops situation where a filesystem was incorrectly increased by an extra order of magnitude *) Unexpected (e.g. emergency) growth of an application which required increasing a filesystem and shrinking another (lesser) used filesystem. Yes in all three aforementioned cases we had to unmount the ext4 filesystem in order to shrink it, however, we would _not_ have been able to do this with xfs. On a semi related note: I grow/shrink JFS2 filesystems (on AIX) all the time. It would be great if ext4 had online shrink. -Jacob -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On 27.02.2014 01:33, Josef Bacik wrote: Just popping in here to say that btrfs is not ready to be default in Fedora yet. Optional is fine but not default. Thanks, Josef This is actually a good news. Thanks. Now all we need is fair support in the installer. BTRFS as alternative scheme: +1 F-Server +1 F-Workstation poma -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
Am 01.03.2014 22:55, schrieb poma: On 27.02.2014 01:33, Josef Bacik wrote: Just popping in here to say that btrfs is not ready to be default in Fedora yet. Optional is fine but not default. Thanks, This is actually a good news. Thanks. Now all we need is fair support in the installer. BTRFS as alternative scheme: +1 F-Server +1 F-Workstation one of the BTRFS maintainers explains is is *not* ready and you start we need in context of BTRFS? strange logic signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Mar 1, 2014, at 2:16 PM, Matthew Miller mat...@fedoraproject.org wrote: On Fri, Feb 28, 2014 at 11:29:30PM -0700, Chris Murphy wrote: - There needs to be a mandate to remove features from custom partitioning that quite frankly don't make sense like rootfs on raid4, raid5 or raid6. OK maybe raid5. But not raid 4 or raid 6. There are other Okay, I'll bite. Why not rootfs on raid6? It's pathological. There are too many simpler, faster, more resilient options considering rootfs at most isn't bigger than the average SSD: Two or three SSDs + n-way mirroring. RAID 10. Or RAID 1 + linear + XFS for deterministic workloads. So even rootfs on raid 5 is pathological. It just looks cool in the installer UI because there is no such offering in Windows or OS X, but I'd limit it to /home or /$other. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Mar 1, 2014, at 3:58 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 01.03.2014 22:55, schrieb poma: On 27.02.2014 01:33, Josef Bacik wrote: Just popping in here to say that btrfs is not ready to be default in Fedora yet. Optional is fine but not default. Thanks, This is actually a good news. Thanks. Now all we need is fair support in the installer. BTRFS as alternative scheme: +1 F-Server +1 F-Workstation one of the BTRFS maintainers explains is is *not* ready and you start we need in context of BTRFS? strange logic Josef said it's not ready to be default. Poma suggested making it available as an alternate to whatever the default is, which is consistent with how Fedora has been for three releases. His suggestion is still fewer permutations than the partition scheme outcomes in Fedora 20; and is about the same or on par with Fedora 18/19, but still one more than oldui. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Mar 1, 2014, at 4:26 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 1, 2014, at 2:16 PM, Matthew Miller mat...@fedoraproject.org wrote: On Fri, Feb 28, 2014 at 11:29:30PM -0700, Chris Murphy wrote: - There needs to be a mandate to remove features from custom partitioning that quite frankly don't make sense like rootfs on raid4, raid5 or raid6. OK maybe raid5. But not raid 4 or raid 6. There are other Okay, I'll bite. Why not rootfs on raid6? It's pathological. There are too many simpler, faster, more resilient options considering rootfs at most isn't bigger than the average SSD: Two or three SSDs + n-way mirroring. RAID 10. Or RAID 1 + linear + XFS for deterministic workloads. Those three examples are simpler, more resilient, easier to configure and maintain, perform better, with faster rebuild times than RAID 6 which also has a high read-modify-write penalty. I left that part out. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
Am 02.03.2014 00:42, schrieb Chris Murphy: On Mar 1, 2014, at 4:26 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 1, 2014, at 2:16 PM, Matthew Miller mat...@fedoraproject.org wrote: On Fri, Feb 28, 2014 at 11:29:30PM -0700, Chris Murphy wrote: - There needs to be a mandate to remove features from custom partitioning that quite frankly don't make sense like rootfs on raid4, raid5 or raid6. OK maybe raid5. But not raid 4 or raid 6. There are other Okay, I'll bite. Why not rootfs on raid6? It's pathological. There are too many simpler, faster, more resilient options considering rootfs at most isn't bigger than the average SSD: Two or three SSDs + n-way mirroring. RAID 10. Or RAID 1 + linear + XFS for deterministic workloads. Those three examples are simpler, more resilient, easier to configure and maintain, perform better, with faster rebuild times than RAID 6 which also has a high read-modify-write penalty. I left that part out. yes, but RAID6 allows a disk-fault *while* rebuild the RAID after the first one RADID 10 *may* do the same if the *right* second disk fails in real life disks are mostly identical old and in case one fails the chance that anotehr one fails within a short timeframe is high and the rebuild makes it even more likely frankly i saw SAN configurations where after remove 20 disks the system said if now anotehr one fails *we maybe* have a problem and in real life the performance penalty is meaningless compared to a complete fail of the array signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Mar 1, 2014, at 2:40 PM, Nathanael Noblet nathan...@gnat.ca wrote: On 03/01/2014 02:18 PM, Chris Murphy wrote: On Mar 1, 2014, at 1:19 PM, Jon jdisn...@gmail.com wrote: The inability to shrink or reduce XFS is rather disappointing. I've seen a few sarcastic remarks along the lines of (paraphrased): why would anyone ever want to shrink a volume? In the context of server, and default installs, why is a valid question. People do shrink volumes, and this lack of flexibility is an important consideration I feel was ignored in the Server WG decision. What is the use case for volume shrinking in a server context? Dual boot is a total edge case for servers. Recently I had a client who required that some data be on an encrypted partition. The servers were rented from a datacenter instead of being cloud based etc. As such you don't have access to the kickstart used to initialize and install the OS. So we had to shrink the rootfs to make room for a new lvm partition for the data. I've had to do that a handful of times for various reasons but the above is the most recent. The servers were rented with a Fedora produced default/automatic/guided partitioning layout? If not, your example is out of scope. We are only talking about this context specifically, not arbitrary examples for shrinking a file system. The Fedora automatic/guided partition layout is a rootfs of 50GB, and any significant additional space goes to a separate /home. So you're saying you'd shrink a 50GB rootfs for encrypted data, rather than blow away the /home LV, make a new LV, encrypt it, then format it? Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Mar 1, 2014, at 4:51 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.03.2014 00:42, schrieb Chris Murphy: On Mar 1, 2014, at 4:26 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 1, 2014, at 2:16 PM, Matthew Miller mat...@fedoraproject.org wrote: On Fri, Feb 28, 2014 at 11:29:30PM -0700, Chris Murphy wrote: - There needs to be a mandate to remove features from custom partitioning that quite frankly don't make sense like rootfs on raid4, raid5 or raid6. OK maybe raid5. But not raid 4 or raid 6. There are other Okay, I'll bite. Why not rootfs on raid6? It's pathological. There are too many simpler, faster, more resilient options considering rootfs at most isn't bigger than the average SSD: Two or three SSDs + n-way mirroring. RAID 10. Or RAID 1 + linear + XFS for deterministic workloads. Those three examples are simpler, more resilient, easier to configure and maintain, perform better, with faster rebuild times than RAID 6 which also has a high read-modify-write penalty. I left that part out. yes, but RAID6 allows a disk-fault *while* rebuild the RAID after the first one RADID 10 *may* do the same if the *right* second disk fails If you need two disk failure tolerance use n-way mirroring with three disks, anaconda supports this. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
Am 02.03.2014 01:36, schrieb Chris Murphy: On Mar 1, 2014, at 4:51 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.03.2014 00:42, schrieb Chris Murphy: On Mar 1, 2014, at 4:26 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 1, 2014, at 2:16 PM, Matthew Miller mat...@fedoraproject.org wrote: On Fri, Feb 28, 2014 at 11:29:30PM -0700, Chris Murphy wrote: - There needs to be a mandate to remove features from custom partitioning that quite frankly don't make sense like rootfs on raid4, raid5 or raid6. OK maybe raid5. But not raid 4 or raid 6. There are other Okay, I'll bite. Why not rootfs on raid6? It's pathological. There are too many simpler, faster, more resilient options considering rootfs at most isn't bigger than the average SSD: Two or three SSDs + n-way mirroring. RAID 10. Or RAID 1 + linear + XFS for deterministic workloads. Those three examples are simpler, more resilient, easier to configure and maintain, perform better, with faster rebuild times than RAID 6 which also has a high read-modify-write penalty. I left that part out. yes, but RAID6 allows a disk-fault *while* rebuild the RAID after the first one RADID 10 *may* do the same if the *right* second disk fails If you need two disk failure tolerance use n-way mirroring with three disks, anaconda supports this and if you need failure tolerance *and* performance? yes, then use commercial SAN storages... signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Mar 1, 2014, at 5:44 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.03.2014 01:36, schrieb Chris Murphy: On Mar 1, 2014, at 4:51 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.03.2014 00:42, schrieb Chris Murphy: On Mar 1, 2014, at 4:26 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 1, 2014, at 2:16 PM, Matthew Miller mat...@fedoraproject.org wrote: On Fri, Feb 28, 2014 at 11:29:30PM -0700, Chris Murphy wrote: - There needs to be a mandate to remove features from custom partitioning that quite frankly don't make sense like rootfs on raid4, raid5 or raid6. OK maybe raid5. But not raid 4 or raid 6. There are other Okay, I'll bite. Why not rootfs on raid6? It's pathological. There are too many simpler, faster, more resilient options considering rootfs at most isn't bigger than the average SSD: Two or three SSDs + n-way mirroring. RAID 10. Or RAID 1 + linear + XFS for deterministic workloads. Those three examples are simpler, more resilient, easier to configure and maintain, perform better, with faster rebuild times than RAID 6 which also has a high read-modify-write penalty. I left that part out. yes, but RAID6 allows a disk-fault *while* rebuild the RAID after the first one RADID 10 *may* do the same if the *right* second disk fails If you need two disk failure tolerance use n-way mirroring with three disks, anaconda supports this and if you need failure tolerance *and* performance? You need better rootfs performance than what's provided by SSD? yes, then use commercial SAN storages… OK, but it sounds expensive and demeaning. Yet, I'll grant that it's more sane than rootfs on software RAID 6. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
Am 02.03.2014 02:11, schrieb Chris Murphy: On Mar 1, 2014, at 5:44 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.03.2014 01:36, schrieb Chris Murphy: On Mar 1, 2014, at 4:51 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 02.03.2014 00:42, schrieb Chris Murphy: On Mar 1, 2014, at 4:26 PM, Chris Murphy li...@colorremedies.com wrote: On Mar 1, 2014, at 2:16 PM, Matthew Miller mat...@fedoraproject.org wrote: On Fri, Feb 28, 2014 at 11:29:30PM -0700, Chris Murphy wrote: - There needs to be a mandate to remove features from custom partitioning that quite frankly don't make sense like rootfs on raid4, raid5 or raid6. OK maybe raid5. But not raid 4 or raid 6. There are other Okay, I'll bite. Why not rootfs on raid6? It's pathological. There are too many simpler, faster, more resilient options considering rootfs at most isn't bigger than the average SSD: Two or three SSDs + n-way mirroring. RAID 10. Or RAID 1 + linear + XFS for deterministic workloads. Those three examples are simpler, more resilient, easier to configure and maintain, perform better, with faster rebuild times than RAID 6 which also has a high read-modify-write penalty. I left that part out. yes, but RAID6 allows a disk-fault *while* rebuild the RAID after the first one RADID 10 *may* do the same if the *right* second disk fails If you need two disk failure tolerance use n-way mirroring with three disks, anaconda supports this and if you need failure tolerance *and* performance? You need better rootfs performance than what's provided by SSD? no, i don't use SSD at all and many don't for good reasons if you do not have endless disk slots and need a lot of storage you have to decide and no place for rootfs on SSD yes, then use commercial SAN storages… OK, but it sounds expensive and demeaning but it works and has 365/7/24 support in case of troubles *that* is the place where Fedora has to fight in case of storage Yet, I'll grant that it's more sane than rootfs on software RAID 6 and that is why my 30 Fedora production servers are running on top of VMware vSphere and a HP SAN storage with RAID6 for many years in that case i do not need to care what Fedora supports sane for rootfs and that is what Fedora needs to beat or the storage area will continue to run commercial storage area of it comes to business signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Thu, 2014-02-27 at 11:56 -0500, Bill Nottingham wrote: Stephen Gallagher (sgall...@redhat.com) said: Directed more broadly at all three products: Formal proposal (for discussion): All three products agree to use ext4 for /boot and XFS-on-LVM for all other partitions in the guided mode. All is fair game in the custom mode. Also, for the sake of everyone's sanity, as we discuss this specific proposal, let's hold the conversation to devel@lists.fedoraproject.org (making this the last cross-posted message in the thread). ... I understand that synergy can help, but given we likely expect usage of all(*) the local fileystems, is there a reason the three produces need to share partitioning setup? (*) well, not reiserfs We can expect use of them, but if all the products agree, then we at least have one default that we can test to destruction. As discussed in another thread around here somewhere, we (QA) would like to return to the clear distinction between custom- and non-custom partitioning, where non-custom is as 'choice-free' as plausible and correspondingly reliable, and custom is a best-effort thing. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Thu, 2014-02-27 at 23:16 -0700, Chris Murphy wrote: On Feb 27, 2014, at 11:07 PM, James Wilson Harshaw IV jwhars...@gmail.com wrote: I apologize, I guess I did not get the whole background out of it. What filesystems are we considering? It's XFS vs ext4 and Server WG has agreed on XFS on LVM. As a server WG member I voted +1 on XFS as I have no particular objection to XFS as a filesystem, but I do think it seems a bit sub-optimal for us to wind up with server and desktop having defaults that are very similar but slightly different, for no apparently great reason. ext4 and xfs are basically what I refer to as 'plain' filesystems (i.e. not all souped-up btrfs/zfs stuff), they're stable, mature, and generally good-enough for just about all cases. Is xfs really so much better for servers, and ext4 so much better for desktops, that it's worth the extra development/maintenance to allow Desktop to use ext4 and Server to use xfs? Basically, what I'm saying is that if Desktop would be OK with using xfs-on-LVM as default with all choices demoted to custom partitioning (no dropdown), as Server has currently agreed on, that'd be great. Or if we could otherwise achieve agreement on something. Right now we seem to be sleepwalking into a situation where server and desktop diverge but no-one particularly *wants* that, which seems a bit off. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Fri, Feb 28, 2014 at 3:16 PM, Adam Williamson awill...@redhat.com wrote: On Thu, 2014-02-27 at 11:56 -0500, Bill Nottingham wrote: Stephen Gallagher (sgall...@redhat.com) said: Directed more broadly at all three products: Formal proposal (for discussion): All three products agree to use ext4 for /boot and XFS-on-LVM for all other partitions in the guided mode. All is fair game in the custom mode. Also, for the sake of everyone's sanity, as we discuss this specific proposal, let's hold the conversation to devel@lists.fedoraproject.org (making this the last cross-posted message in the thread). ... I understand that synergy can help, but given we likely expect usage of all(*) the local fileystems, is there a reason the three produces need to share partitioning setup? (*) well, not reiserfs We can expect use of them, but if all the products agree, then we at least have one default that we can test to destruction. As discussed in another thread around here somewhere, we (QA) would like to return to the clear distinction between custom- and non-custom partitioning, where non-custom is as 'choice-free' as plausible and correspondingly reliable, and custom is a best-effort thing. Can you elaborate on how that's eases the test matrix? As I said in a conversation with Stephen yesterday, I don't think it's the case that a common layout in partitions/fs is actually reducing the test load. From a component standpoint, sure absolutely it is. One filesystem to test is easier than 3. However, we don't do _filesystem_ testing in the context of release testing. It's implicit in the other tests. So if we have 3 products, which deliver 3 different install media, then we still have 3 different things to test regardless of the FS/partition scheme chosen by default. Cloud is delivering cloud images. Workstation is looking at a live image as it's default deliverable, and I believe Server is looking at a more traditional install approach (with it being the only OS on the machine). Given they all have completely different ways of doing the install, having a common fs and layout doesn't particularly change the fact that they all still need to be tested. I do agree on the custom vs. non-custom part, and having the install options in each media as choice-free as possible will help overall. Having to do multiple iterations over each product install approach makes things even harder. I think that if the defaults happen to be the same it's a bonus, but not a requirement. And before anybody yells at me, I fully expect the WGs and people working on the products will need to significantly pitch in on the QA front to ensure their product install is viable. It comes with the change that's being done. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Fri, Feb 28, 2014 at 3:45 PM, Adam Williamson awill...@redhat.com wrote: On Thu, 2014-02-27 at 23:16 -0700, Chris Murphy wrote: On Feb 27, 2014, at 11:07 PM, James Wilson Harshaw IV jwhars...@gmail.com wrote: I apologize, I guess I did not get the whole background out of it. What filesystems are we considering? It's XFS vs ext4 and Server WG has agreed on XFS on LVM. As a server WG member I voted +1 on XFS as I have no particular objection to XFS as a filesystem, but I do think it seems a bit sub-optimal for us to wind up with server and desktop having defaults that are very similar but slightly different, for no apparently great reason. ext4 and xfs are basically what I refer to as 'plain' filesystems (i.e. not all souped-up btrfs/zfs stuff), they're stable, mature, and generally good-enough for just about all cases. Is xfs really so much better for servers, and ext4 so much better for desktops, that it's worth the extra development/maintenance to allow Desktop to use ext4 and Server to use xfs? I asked about the why on XFS for Server this morning. Stephen and Matthias both pointed out that it very much has to do with the work done for RHEL7, since they went with XFS there. That choice wouldn't have been made lightly. I believe Stephen was going to write up some rationale on it. Basically, what I'm saying is that if Desktop would be OK with using xfs-on-LVM as default with all choices demoted to custom partitioning (no dropdown), as Server has currently agreed on, that'd be great. Or if we could otherwise achieve agreement on something. I'll bring it up. I believe the momentum on using ext4-on-LVM is that it's the existing default, it's a known quantity, and we have the most experience with it as a project. Right now we seem to be sleepwalking into a situation where server and desktop diverge but no-one particularly *wants* that, which seems a bit off. Yeah. It's those crazy Server people causing trouble by messing with the status-quo and changing the defaults... ;) josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
Josh Boyer (jwbo...@fedoraproject.org) said: Basically, what I'm saying is that if Desktop would be OK with using xfs-on-LVM as default with all choices demoted to custom partitioning (no dropdown), as Server has currently agreed on, that'd be great. Or if we could otherwise achieve agreement on something. I'll bring it up. I believe the momentum on using ext4-on-LVM is that it's the existing default, it's a known quantity, and we have the most experience with it as a project. So, we're combining momentum on using the existing default for a Fedora deliverable and the existing default for a RHEL deliverable to get two different defaults? (I'd note that RHEL Workstation, at least in the beta, defaults to XFS as well, although I think that's merely inheriting from the Server cases.) Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Fri, 2014-02-28 at 15:46 -0500, Josh Boyer wrote: On Fri, Feb 28, 2014 at 3:16 PM, Adam Williamson awill...@redhat.com wrote: On Thu, 2014-02-27 at 11:56 -0500, Bill Nottingham wrote: Stephen Gallagher (sgall...@redhat.com) said: Directed more broadly at all three products: Formal proposal (for discussion): All three products agree to use ext4 for /boot and XFS-on-LVM for all other partitions in the guided mode. All is fair game in the custom mode. Also, for the sake of everyone's sanity, as we discuss this specific proposal, let's hold the conversation to devel@lists.fedoraproject.org (making this the last cross-posted message in the thread). ... I understand that synergy can help, but given we likely expect usage of all(*) the local fileystems, is there a reason the three produces need to share partitioning setup? (*) well, not reiserfs We can expect use of them, but if all the products agree, then we at least have one default that we can test to destruction. As discussed in another thread around here somewhere, we (QA) would like to return to the clear distinction between custom- and non-custom partitioning, where non-custom is as 'choice-free' as plausible and correspondingly reliable, and custom is a best-effort thing. Can you elaborate on how that's eases the test matrix? Sure. Just a bit below... As I said in a conversation with Stephen yesterday, I don't think it's the case that a common layout in partitions/fs is actually reducing the test load. From a component standpoint, sure absolutely it is. One filesystem to test is easier than 3. However, we don't do _filesystem_ testing in the context of release testing. We attempt to test all paths through non-custom installation. Well, at present we don't cover this very well, but it's always been what QA was *supposed* to do. Right now, what we have is this mess: https://fedoraproject.org/wiki/QA:Fedora_20_Install_Results_Template#General_Tests the tests listed as Partitioning. They are, really, held over from oldUI: their instructions have been modified to suit newUI, but the actual logic of *what tests we have* is based almost entirely on the oldUI interface. It covers, quite well, all the non-custom choices oldUI offered. It does not cover all the non-custom choices offered in newUI as of F20. It comes off as a pretty much random hodgepodge. We have a test which is just 'go into custom partitioning and...do something'. We have tests for various filesystems 'as the root fs', but not any of the other things newUI will do if you pick a variant filesystem. It just doesn't make an awful lot of sense. So, at the start of the F21 cycle, I tried to come up with a new approach to installer partitioning testing that actually covered what we're supposed to be covering. Chris spent some time thinking about this too. What I came up with is this gem: https://fedoraproject.org/wiki/User:Adamwill/Draft_storage_matrix There's 28 tests there just to cover the basics of what non-custom partitioning offers (it still doesn't cover everything). That's a lot of testing when we tend to iterate a TC/RC every three or four days. And we have a wonderful set of possible 'variant' factors which just make everything explode exponentially if you think about it too hard - we kinda need those tables to be *three (or more!) dimensional*, because the 'Device tests' don't consider filesystems, and the 'filesystem tests' don't consider backing devices or architectures (sure, but does it work on ARM?) I hope this goes some way to explaining why we're strongly in favour of as much simplification on the non-custom path (or 'paths', now we have multiple products) as is practical. :) Some of this is susceptible to automation, but some is not, in the sense that it involves the UI, and automated UI testing is a giant PITA. And 'susceptible to automation' is all very well, but it requires someone to do the work of automating it. It's been on my todo list for a while to at least come up with a collection of kickstarts that exercises the options that are easy to do with a straight kickstart from an empty VM, but that's only making a small dent in the problem, really. If you want to follow our discussion, here's some probably-good entry points: https://lists.fedoraproject.org/pipermail/test/2013-December/119447.html https://lists.fedoraproject.org/pipermail/test/2013-December/119587.html https://lists.fedoraproject.org/pipermail/test/2013-December/119604.html It's implicit in the other tests. That's kind of one of our major problems right now: implicit in other tests testing sucks, because you don't find things early enough or in an organized enough way. Hey, I was testing this other thing and I found a storage bug! lends itself to vague bug reports and us forgetting to keep testing the thing that caused the problem and so not catching regressions, and stuff... So if we have 3 products, which deliver 3
Re: default file system, was: Comparison to Workstation Technical Specification
On Fri, Feb 28, 2014 at 4:02 PM, Bill Nottingham nott...@redhat.com wrote: Josh Boyer (jwbo...@fedoraproject.org) said: Basically, what I'm saying is that if Desktop would be OK with using xfs-on-LVM as default with all choices demoted to custom partitioning (no dropdown), as Server has currently agreed on, that'd be great. Or if we could otherwise achieve agreement on something. I'll bring it up. I believe the momentum on using ext4-on-LVM is that it's the existing default, it's a known quantity, and we have the most experience with it as a project. So, we're combining momentum on using the existing default for a Fedora deliverable and the existing default for a RHEL deliverable to get two different defaults? Physics sucks huh? Isn't this what they call an elastic collision? That's the one where things collide and then go off in different directions, right? (I'd note that RHEL Workstation, at least in the beta, defaults to XFS as well, although I think that's merely inheriting from the Server cases.) Fair point. As I said, I'll bring it up. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Thu, 2014-02-27 at 14:31 -0700, Chris Murphy wrote: On Feb 27, 2014, at 1:13 PM, Josh Boyer jwbo...@fedoraproject.org wrote: On Thu, Feb 27, 2014 at 3:07 PM, Chris Murphy li...@colorremedies.com wrote: http://meetbot.fedoraproject.org/fedora-meeting-1/2014-02-27/fedora-meeting-1.2014-02-27-15.00.log.html OK super, pretty much all Server WG questions are answered. That was easy. Summary is they are going to go with XFS on LVM. LVM vs LVM thinp is to be determined. And they only want this one option for the guided path (i.e. sounds like Partition Scheme pop-up goes away). For Workstation WG it can be the same thing too. Or optionally pick an alternate: plain partition (probably ext4), or Btrfs. Not btrfs. We answered that yesterday. I know that, no Btrfs by default. The above pertains to an (optional) alternate. I'd really like it if we can drop btrfs to custom partitioning. I really don't like this 'it's not really ready to be default but we're going to offer it in a way that makes it look as good as the default choice' thing. Also, custom part has the 'choose your own adventure' dropdown itself now. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Feb 28, 2014, at 1:45 PM, Adam Williamson awill...@redhat.com wrote: On Thu, 2014-02-27 at 23:16 -0700, Chris Murphy wrote: It's XFS vs ext4 and Server WG has agreed on XFS on LVM. As a server WG member I voted +1 on XFS as I have no particular objection to XFS as a filesystem, but I do think it seems a bit sub-optimal for us to wind up with server and desktop having defaults that are very similar but slightly different, for no apparently great reason. There are good reasons to use XFS by default for Server. I wrote out a list of reasons in favor of plain ext4 for Workstation. [1] But then I saw this little line in the Workstation PRD: While the developer workstation is the main target of this system and what we try to design this for, we do of course also welcome other users to the Fedora Workstation. So my little plain ext4 list is maybe ignorable if there's some good reason why developers should have LVM by default. I see no disadvantage or advantage of developers having ext4 vs XFS. So that part is a wash. The way I'd decide this is if simplicity meets the requirements of developers, then do that, and do it with ext4. If they need LVM, then I'd go with parity with Server and do XFS on LVM (or LVMthinp if they do that). Is xfs really so much better for servers, and ext4 so much better for desktops, that it's worth the extra development/maintenance to allow Desktop to use ext4 and Server to use xfs? There are advantages for server using XFS, even for the smaller percent (?) who may end up using the default installation path. There's no negative I think of for Workstation using XFS. So I'd say make them both XFS. Basically, what I'm saying is that if Desktop would be OK with using xfs-on-LVM as default with all choices demoted to custom partitioning (no dropdown), as Server has currently agreed on, that'd be great. Yes. Right now we seem to be sleepwalking into a situation where server and desktop diverge but no-one particularly *wants* that, which seems a bit off. Yeah. I pretty much see it as an LVM question. If not LVM, sure ext4 meets the requirements and it's a very slightly simpler layout because we'd need an ext4 boot anyway. If yes to LVM, just do what Server is doing. Workstation isn't hurt by it. Chris Murphy [1] Reasons in favor of plain ext4 for Workstation. 1. It's simple to install, test, and for the user to maintain and understand. 2. Most users, especially Windows and OS X users, don't grok LVM at all and don't benefit from it. 3. It's the layout most users new to Linux are used to. 4. The anaconda team was going to use plain ext4 in Fedora 18 with newui. 5. Would simplify custom partitioning's click here to create them automatically as a starting point. 6. It will in fact boot the computer. The only way to get any simpler is a single ext4 partition including use of a swapfile. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Feb 28, 2014, at 1:46 PM, Josh Boyer jwbo...@gmail.com wrote: Can you elaborate on how that's eases the test matrix? As I said in a conversation with Stephen yesterday, I don't think it's the case that a common layout in partitions/fs is actually reducing the test load. From a component standpoint, sure absolutely it is. One filesystem to test is easier than 3. However, we don't do _filesystem_ testing in the context of release testing. It's implicit in the other tests. Mostly true. Contra example from Fedora 20: LVM Thin Provisioning landed either right at or just before branch as a Guided partitioning option. And it either didn't install or the installation wasn't bootable, until just before beta, and then blew up before release. So that's a lot of testing done for something that quite frankly not a lot of users were interested in, yet because QA didn't rerun its entire matrix of tests, include testing this one partition scheme option, it shipped broken. And that's kinda annoying because a.) it's a prominently available feature by being in the guided partitioning path, b.) because probably several hundred man hours went into it and because 1 more hour wasn't committed it blew up for shipping because we didn't know until after committing to release that it was broken. And that happened in large part because QA spends increasing amounts of time also on testing the custom partitioning section compared to oldui. So I'd say one of two things about custom partitioning must become true going forward. - Custom partitioning is best effort in that it's entirely possible (maybe even likely) something ships that doesn't work. And that's because no one (or too few) are testing that particular combination of features. - There needs to be a mandate to remove features from custom partitioning that quite frankly don't make sense like rootfs on raid4, raid5 or raid6. OK maybe raid5. But not raid 4 or raid 6. There are other examples I'm sure. Or some combination of the two. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/27/2014 12:18 AM, Chris Murphy wrote: On Feb 26, 2014, at 5:33 PM, Josef Bacik jo...@toxicpanda.com mailto:jo...@toxicpanda.com wrote: Just popping in here to say that btrfs is not ready to be default in Fedora yet. Optional is fine but not default. OK good, that's definitive. Thanks Josef. So my thought is Workstation WG choices: parity with Server WG, whatever they choose; or plain ext4; or keep things the same with LVM + ext4. And on the question of an alternate choice (what currently appears in the Automatic/Guided path's Partition Scheme pop-up menu) the WG's might consider this too, even whether an alternate is desired. Because from a my personal QA perspective, I'd like to see the two products agree on either the default or an alternate so we don't have four total possible paths combined, which today means 100 testable outcomes. One or two paths is ideal; three might be OK. Four is like… chickens with no heads, running. Speaking for myself, I have a slight preference on using XFS-on-LVM for the default filesystem in the Fedora Server, but if both of the other Products would prefer ext4-on-LVM, I suppose we could negotiate. If we can arrange things so we only have a single installer with different install targets (at least for the net install), I'd consider the reduction in testing effort at least worthy of argument at being more valuable than the filesystem choice. Question for the cloud folks: I realize that XFS is a difficult pill to swallow for /boot, due to your use of syslinux instead of GRUB2. If the Server and Workstation groups decide to settle on both using XFS-on-LVM for the main partitions, we could *probably* also compromise on using ext4 for just /boot. Directed more broadly at all three products: Formal proposal (for discussion): All three products agree to use ext4 for /boot and XFS-on-LVM for all other partitions in the guided mode. All is fair game in the custom mode. Also, for the sake of everyone's sanity, as we discuss this specific proposal, let's hold the conversation to devel@lists.fedoraproject.org (making this the last cross-posted message in the thread). -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMPMwkACgkQeiVVYja6o6OMDgCgpflR85zdgCFaGKPRp1z8WUnI ZbAAoJT2KdC5Pzx6XTo7Ju+x+PO+g13X =q//v -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/27/2014 07:53 AM, Rui Tiago Cação Matos wrote: On 27 February 2014 13:43, Stephen Gallagher sgall...@redhat.com wrote: Formal proposal (for discussion): All three products agree to use ext4 for /boot and XFS-on-LVM for all other partitions in the guided mode. All is fair game in the custom mode. What's the point of using LVM for the root filesystem? As it happens, I can cite a perfect example of this from my own experiences in the last week :) I have a hard drive in the Fedora server I run in my basement that has started throwing intermittent I/O errors. Fortunately for me, I set it up on LVM. I went out, bought a new hard drive, inserted it, added it to the volume group and then ran 'pvmove' to migrate all of the sectors off of the original drive to the new one. Once that was done, I could safely remove the defective drive from the volume group. Zero downtime, perfect recovery. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMPNxQACgkQeiVVYja6o6NUgwCfQBaeyxetR65NsQaiDG9Do6xP 4ykAnjGtTuNMajgOsWlsLtIPITB4DNJ+ =al3R -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
Fortunately for me, I set it up on LVM. I went out, bought a new hard drive, inserted it, added it to the volume group and then ran 'pvmove' to migrate all of the sectors off of the original drive to the new one. What did you do with your /boot partition? -Jacob -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/27/2014 08:10 AM, Jacob Yundt wrote: Fortunately for me, I set it up on LVM. I went out, bought a new hard drive, inserted it, added it to the volume group and then ran 'pvmove' to migrate all of the sectors off of the original drive to the new one. What did you do with your /boot partition? /boot was actually on a separate disk, so I'll admit that's a bit special. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlMPOvYACgkQeiVVYja6o6M1CACeKix3eClclp6XyFR6Vl6L/m18 1eQAnixLFBqQfSSiIm94q8bOWb2fJ3eg =hFIk -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
Stephen Gallagher (sgall...@redhat.com) said: Directed more broadly at all three products: Formal proposal (for discussion): All three products agree to use ext4 for /boot and XFS-on-LVM for all other partitions in the guided mode. All is fair game in the custom mode. Also, for the sake of everyone's sanity, as we discuss this specific proposal, let's hold the conversation to devel@lists.fedoraproject.org (making this the last cross-posted message in the thread). ... I understand that synergy can help, but given we likely expect usage of all(*) the local fileystems, is there a reason the three produces need to share partitioning setup? (*) well, not reiserfs Bill -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Feb 27, 2014, at 5:43 AM, Stephen Gallagher sgall...@redhat.com wrote: Question for the cloud folks: I realize that XFS is a difficult pill to swallow for /boot, due to your use of syslinux instead of GRUB2. If the Server and Workstation groups decide to settle on both using XFS-on-LVM for the main partitions, we could *probably* also compromise on using ext4 for just /boot. I don't think Cloud will use Anaconda UI, instead they use pre-built images or kickstart and thus stick with plain ext4. If that remains the case, then Server can still go with XFS on LVM. Directed more broadly at all three products: Formal proposal (for discussion): All three products agree to use ext4 for /boot and XFS-on-LVM for all other partitions in the guided mode. Discussion by WG members should include whether there should be an alternate, or only the default. Currently the guided UI has four choices. If yes to alternate option (rather than removing the Partition Scheme pop-up altogether), here are several possibilities that make sense to me, variations are possible. The default is listed first, the alternate second. Existing default, new option for Server SERVER WORKSTATION ext4 /boot, LVM+ext4same ext4 /boot, LVM+XFS plain ext4 Existing default, new option for server and NextNewThing for Workstation SERVER WORKSTATION ext4 /boot, LVM+ext4same ext4 /boot, LVM+XFS Btrfs Conservative default, NextNewThing for Server Workstation SERVER WORKSTATION ext4 /boot, LVM+XFS same ext4 /boot, LVMthinp+XFSBtrfs Conservative default and alternate SERVER WORKSTATION ext4 /boot, LVM+XFS same plain XFS* plain ext4 Better for Server, Easier for new/Windows/OS X users SERVER WORKSTATION ext4 /boot, LVM+XFS plain ext4 ext4 /boot, LVMthinp+XFSno alternate appears *GRUB2 has no problem directly booting from XFS for some time now, but probably we'd continue to put /boot on ext4 in all plain partition configurations. Also this guided UI permits the selection of multiple devices. So the WG's might consider how/when to discuss that, if it's a good idea. Today if 2+ devices are chosen, the LVM default creates linear LV's that span the multiple disk VG. For btrfs, the chosen devices are put in a raid0. There is no UI to indicate this, it just happens. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Thu, Feb 27, 2014 at 07:43:53AM -0500, Stephen Gallagher wrote: I realize that XFS is a difficult pill to swallow for /boot, due to your use of syslinux instead of GRUB2. If the Server and Workstation groups decide to settle on both using XFS-on-LVM for the main partitions, we could *probably* also compromise on using ext4 for just /boot. Right now, the cloud images are unpartitioned. In some cloud providers (e.g., the 800lb gorilla of Amazon EC2) we in fact use the kernel that assumes the image is just one partition, not a disk image. We could change that (and I kind of want to anyway, for consistency), but it would be... change. Having a separate /boot is also problematic (read: wasteful) for ultra-small images, and adds complexity a lot of users are going to frown at. So. if by /boot you mean the partition that /boot happens to be on, even if it is /, then I think we're good. Otherwise we will have to figure something else out. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Feb 27, 2014, at 12:22 PM, Chris Murphy li...@colorremedies.com wrote: On Feb 27, 2014, at 5:43 AM, Stephen Gallagher sgall...@redhat.com wrote: Question for the cloud folks: I realize that XFS is a difficult pill to swallow for /boot, due to your use of syslinux instead of GRUB2. If the Server and Workstation groups decide to settle on both using XFS-on-LVM for the main partitions, we could *probably* also compromise on using ext4 for just /boot. I don't think Cloud will use Anaconda UI, instead they use pre-built images or kickstart and thus stick with plain ext4. If that remains the case, then Server can still go with XFS on LVM. Directed more broadly at all three products: Formal proposal (for discussion): All three products agree to use ext4 for /boot and XFS-on-LVM for all other partitions in the guided mode. Discussion by WG members should include whether there should be an alternate, or only the default. Currently the guided UI has four choices. If yes to alternate option (rather than removing the Partition Scheme pop-up altogether), here are several possibilities that make sense to me, variations are possible. The default is listed first, the alternate second. Existing default, new option for Server SERVER WORKSTATION ext4 /boot, LVM+ext4same ext4 /boot, LVM+XFS plain ext4 Existing default, new option for server and NextNewThing for Workstation SERVER WORKSTATION ext4 /boot, LVM+ext4same ext4 /boot, LVM+XFS Btrfs Conservative default, NextNewThing for Server Workstation SERVER WORKSTATION ext4 /boot, LVM+XFS same ext4 /boot, LVMthinp+XFSBtrfs Conservative default and alternate SERVER WORKSTATION ext4 /boot, LVM+XFS same plain XFS* plain ext4 Better for Server, Easier for new/Windows/OS X users SERVER WORKSTATION ext4 /boot, LVM+XFS plain ext4 ext4 /boot, LVMthinp+XFSno alternate appears *GRUB2 has no problem directly booting from XFS for some time now, but probably we'd continue to put /boot on ext4 in all plain partition configurations. Also this guided UI permits the selection of multiple devices. So the WG's might consider how/when to discuss that, if it's a good idea. Today if 2+ devices are chosen, the LVM default creates linear LV's that span the multiple disk VG. For btrfs, the chosen devices are put in a raid0. There is no UI to indicate this, it just happens. http://meetbot.fedoraproject.org/fedora-meeting-1/2014-02-27/fedora-meeting-1.2014-02-27-15.00.log.html OK super, pretty much all Server WG questions are answered. That was easy. Summary is they are going to go with XFS on LVM. LVM vs LVM thinp is to be determined. And they only want this one option for the guided path (i.e. sounds like Partition Scheme pop-up goes away). For Workstation WG it can be the same thing too. Or optionally pick an alternate: plain partition (probably ext4), or Btrfs. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Thu, Feb 27, 2014 at 3:07 PM, Chris Murphy li...@colorremedies.com wrote: http://meetbot.fedoraproject.org/fedora-meeting-1/2014-02-27/fedora-meeting-1.2014-02-27-15.00.log.html OK super, pretty much all Server WG questions are answered. That was easy. Summary is they are going to go with XFS on LVM. LVM vs LVM thinp is to be determined. And they only want this one option for the guided path (i.e. sounds like Partition Scheme pop-up goes away). For Workstation WG it can be the same thing too. Or optionally pick an alternate: plain partition (probably ext4), or Btrfs. Not btrfs. We answered that yesterday. Workstation is likely to go with the existing defaults of the desktop spin unless someone comes up with majorly compelling reasons to change it. Parity with the Server choices isn't really significant given the current thinking on image delivery. josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Thu, 2014-02-27 at 13:07 -0700, Chris Murphy wrote: On Feb 27, 2014, at 12:22 PM, Chris Murphy li...@colorremedies.com wrote: On Feb 27, 2014, at 5:43 AM, Stephen Gallagher sgall...@redhat.com wrote: Question for the cloud folks: I realize that XFS is a difficult pill to swallow for /boot, due to your use of syslinux instead of GRUB2. If the Server and Workstation groups decide to settle on both using XFS-on-LVM for the main partitions, we could *probably* also compromise on using ext4 for just /boot. I don't think Cloud will use Anaconda UI, instead they use pre-built images or kickstart and thus stick with plain ext4. If that remains the case, then Server can still go with XFS on LVM. Directed more broadly at all three products: Formal proposal (for discussion): All three products agree to use ext4 for /boot and XFS-on-LVM for all other partitions in the guided mode. Discussion by WG members should include whether there should be an alternate, or only the default. Currently the guided UI has four choices. If yes to alternate option (rather than removing the Partition Scheme pop-up altogether), here are several possibilities that make sense to me, variations are possible. The default is listed first, the alternate second. Existing default, new option for Server SERVER WORKSTATION ext4 /boot, LVM+ext4same ext4 /boot, LVM+XFS plain ext4 Existing default, new option for server and NextNewThing for Workstation SERVER WORKSTATION ext4 /boot, LVM+ext4same ext4 /boot, LVM+XFS Btrfs Conservative default, NextNewThing for Server Workstation SERVER WORKSTATION ext4 /boot, LVM+XFS same ext4 /boot, LVMthinp+XFSBtrfs Conservative default and alternate SERVER WORKSTATION ext4 /boot, LVM+XFS same plain XFS* plain ext4 Better for Server, Easier for new/Windows/OS X users SERVER WORKSTATION ext4 /boot, LVM+XFS plain ext4 ext4 /boot, LVMthinp+XFSno alternate appears *GRUB2 has no problem directly booting from XFS for some time now, but probably we'd continue to put /boot on ext4 in all plain partition configurations. Also this guided UI permits the selection of multiple devices. So the WG's might consider how/when to discuss that, if it's a good idea. Today if 2+ devices are chosen, the LVM default creates linear LV's that span the multiple disk VG. For btrfs, the chosen devices are put in a raid0. There is no UI to indicate this, it just happens. http://meetbot.fedoraproject.org/fedora-meeting-1/2014-02-27/fedora-meeting-1.2014-02-27-15.00.log.html OK super, pretty much all Server WG questions are answered. That was easy. Summary is they are going to go with XFS on LVM. LVM vs LVM thinp is to be determined. And they only want this one option for the guided path (i.e. sounds like Partition Scheme pop-up goes away). For Workstation WG it can be the same thing too. Or optionally pick an alternate: plain partition (probably ext4), or Btrfs. Chris Murphy My question may seem dumb, but will the systems still function without the net? Cloud services are wonderful in their promise, but my experience with availability of the net lead me to be suspicious, and the speed of the net is still abysmal for many of the types of things I do, such as DSP, AI programming, embedded device support, in depth interactive analysis of some kinds of digital data, or interactive conversion of programs between programming languages and/or platforms. I do know that the net offers powerful parallel processing, powerful language and platform independence for all kinds of big data, and of course the real-time perusal of the net itself and its contents. But the cloud type of services also offer the spread of potent platform independent virus programs, unknown destinations of your data and programs, along with the risks associated with cross border support of some kinds of programs and data. There can also be legal repercussions in some cases should some treaty, law or other rule be broken in the containment, transmission and operation of such programs. So how is that to be handled? Regards, Les H -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 27 Feb 2014 15:01:47 -0500 Matthew Miller mat...@fedoraproject.org wrote: On Thu, Feb 27, 2014 at 07:43:53AM -0500, Stephen Gallagher wrote: I realize that XFS is a difficult pill to swallow for /boot, due to your use of syslinux instead of GRUB2. If the Server and Workstation groups decide to settle on both using XFS-on-LVM for the main partitions, we could *probably* also compromise on using ext4 for just /boot. Right now, the cloud images are unpartitioned. In some cloud providers (e.g., the 800lb gorilla of Amazon EC2) we in fact use the kernel that assumes the image is just one partition, not a disk image. We could change that (and I kind of want to anyway, for consistency), but it would be... change. Having a separate /boot is also problematic (read: wasteful) for ultra-small images, and adds complexity a lot of users are going to frown at. So. if by /boot you mean the partition that /boot happens to be on, even if it is /, then I think we're good. Otherwise we will have to figure something else out. u-boot has zero support for xfs so arm systems will have to use ext4 for /boot at least as well. which would mean / if users chose to not use a separate /boot partition Dennis -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTD6dDAAoJEH7ltONmPFDR2vIP/1UwuBljIlxWvuVOYMp1DkSm zj1svbpIDQAsrOyTjVBr/wpGzTN87YdnFjszf86YUaWq75TJqHMC0vEw/zO22ito vK4dkbH0do0FzDlJi0YpQT2tgWh7EY89yDCSrU+NIml0MkFbAeLJMGzpIhCX3eIt FMCi34n6dXNo1XIWSFFC4EINN7NV9ST/NYnOS7VPM49DERiiBDS39HZjNuPuvH0S XjLpwObuLQ8i/kH++U8sBOSticImAgHZ1GWtHjrJdlT3X9SYrgUqcTNhfLJ95iAr bSjm3aCmcZEVtAs8UrVx55wjQzyFaX4Mp3lzrwAVz91NUovY4tj/NVd/I0c1VnQ5 Ra0GgIKAWKukm++f2UM/uxIUgWCC5irC5fCi0vJwa9ZCd+GCoRJ4rhxLAEG0cIkd O0SWkaYDV/oCQmFpYL3hh3X7+dWTTZ7vAFdqxSB88K0NAfCd/C+2Qzg7YMC5UhZb hiY1Zmwx7Unt5jM0FHefuHgQmTuhq9G9VGm+zobLv0BAZTO/FqxUTGxfujg3AtTT f+Vb6h+LuRaNWx/vEdnpeD/21/yWAhl6Sn9XEyB0/Cwc8MTGRZhcKAtaOAq73/sd WcauN2uUO8vGp9T+xwnU47g3zAxbfIMd3fsr5ibMIh3GzX3A+soVy5prg2MDX7FT 0tWptq1/zM+i2AMjRwRQ =KpHb -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Thu, Feb 27, 2014 at 3:59 PM, Dennis Gilmore den...@ausil.us wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 27 Feb 2014 15:01:47 -0500 Matthew Miller mat...@fedoraproject.org wrote: On Thu, Feb 27, 2014 at 07:43:53AM -0500, Stephen Gallagher wrote: I realize that XFS is a difficult pill to swallow for /boot, due to your use of syslinux instead of GRUB2. If the Server and Workstation groups decide to settle on both using XFS-on-LVM for the main partitions, we could *probably* also compromise on using ext4 for just /boot. Right now, the cloud images are unpartitioned. In some cloud providers (e.g., the 800lb gorilla of Amazon EC2) we in fact use the kernel that assumes the image is just one partition, not a disk image. We could change that (and I kind of want to anyway, for consistency), but it would be... change. Having a separate /boot is also problematic (read: wasteful) for ultra-small images, and adds complexity a lot of users are going to frown at. So. if by /boot you mean the partition that /boot happens to be on, even if it is /, then I think we're good. Otherwise we will have to figure something else out. u-boot has zero support for xfs so arm systems will have to use ext4 for /boot at least as well. which would mean / if users chose to not use a separate /boot partition Or, as an alternative, XFS support could be added to u-boot and/or syslinux. Never eliminate the possibility of actually writing code to fix problems. All it takes is someone willing to do work ;). josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: default file system, was: Comparison to Workstation Technical Specification
On Thu, Feb 27, 2014 at 04:03:06PM -0500, Josh Boyer wrote: Or, as an alternative, XFS support could be added to u-boot and/or syslinux. Never eliminate the possibility of actually writing code to fix problems. All it takes is someone willing to do work ;). Right, and as I understand it, there actually _is_ some level of support, and there was a GSoC project related to it a couple of years ago. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
