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? 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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
