On 04/13/2014 02:50 PM, Greg Freemyer wrote:
On Sun, Apr 13, 2014 at 5:20 PM, Lew Wolfgang
wrote: To refresh memories, XFS now defaults to spreading its inodes out across the whole partition, which on partitions larger than 1-TB will break 32-bit applications. Lew,
I think you mean 32-bit maintenance applications that read the raw filesystem. Not very many of those in the real world. And yes it only seems logical that if you want to work with large filesystems you need a 64-bit kernel and associated filesystem utilities.
Hi Greg, This is with 64-bit distributions and kernels. Been using that since the first AMD Opteron days. Maybe I should have said "some" 32-bit applications. I ran into the problem with acroread last year: http://forums.adobe.com/message/4721987 Then, last week I ran into the same issue with Xilinx 10.1, which is an old-ish FPGA compiler. These packages weren't reading the raw device, they weren't able to "stat" a file if it's inode location was more than 1-TB from the beginning of the filesystem. I guess the block pointers are 32-bit signed integers, giving only 31-bits of block addressing? (this is from memory last year) The applications would crash with file-not-found kinds of messages, while the files were really there for a 64-bit application. The default openSuSE behavior for XFS used to be inode32, but that silently changed a year or so ago. My fix was to reformat in ext4 for desktops, but to leave XFS inode64 for the raid servers with the huge partitions. I forgot about this and accidentally formatted a desktop with XFS-64 last week. Got bit right away... So I guess that ext[34] always clusters their inodes below 1-TB? Maybe that's why XFS handles large partitions more efficiently? I tried BTRFS almost two years ago and had it crash horribly when writing above 16-TB or so. I think I even made a bug report about that one. Regards, Lew -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org