On Mon, Mar 3, 2014 at 9:01 PM, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> wrote: > > On Mar 3, 2014, at 4:57 PM, Jon <jdisnard@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- -Jon -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
