On Sat, 2014-03-01 at 12:04 +0000, Ian Malone wrote: > On 28 February 2014 20:45, Adam Williamson <awilliam@xxxxxxxxxx> 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 <jwharshaw@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
