On Mar 3, 2014, at 4:57 PM, Jon <jdisnard(a)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