[opensuse-factory] BTRFS and old 32-bit programs
Hi Folks, I was bitten by the default XFS inode64 configuration again last week. 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. This time it was a FPGA compiler and acroread. XFS can be created/mounted so that all the inodes are clustered at the low end of the partition, but this can lead to other issues. I now wonder if BTRFS will have a similar issue with large filesystems? Will BTRFS treat old 32-bit programs well? About 30-minutes of searching on Google didn't answer the question. We're currently using partitions as large as 77-TB to store and process many thousands of 4-GB binary files. Regards, Lew -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Apr 13, 2014 at 5:20 PM, Lew Wolfgang <wolfgang@sweet-haven.com> 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. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/13/2014 02:50 PM, Greg Freemyer wrote:
On Sun, Apr 13, 2014 at 5:20 PM, Lew Wolfgang <wolfgang@sweet-haven.com> 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
Lew Wolfgang <wolfgang@sweet-haven.com> writes:
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?
There are no block pointers in user space. The issue is that the inode number does not fit in ino_t without LFS (_FILE_OFFSET_BITS=32). Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 04/14/2014 12:17 AM, Andreas Schwab wrote:
Lew Wolfgang <wolfgang@sweet-haven.com> writes:
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? There are no block pointers in user space. The issue is that the inode number does not fit in ino_t without LFS (_FILE_OFFSET_BITS=32).
Hi Andreas, I know nothing about this, but is the block number reflected in the inode number? It must, or moving all the inodes to the first terabyte of an XFS partition wouldn't make any difference. Does btrfs have a similar issue? I'm just trying to anticipate potential future issues. Regards, Lew -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 2014-04-14 16:01, Lew Wolfgang wrote:
I know nothing about this, but is the block number reflected in the inode number?
It may, but there is no reason it _has_ to. Especially when you start having redundant copies of data (as is possible with btrfs), you cannot tell all the locations just from the inode number alone without further information. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (4)
-
Andreas Schwab -
Greg Freemyer -
Jan Engelhardt -
Lew Wolfgang