On 1 March 2014 18:57, Simo Sorce <simo@xxxxxxxxxx> wrote: > 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: >> 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@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
