On 2/18/13 5:11 PM, John Reiser wrote:
> On 02/18/2013 01:33 PM, Eric Sandeen wrote:
>> XFS recently defaulted to allowing > 32 bit inode numbers, and btrfs can let
>> inode numbers creep past 2^32 as well.
>>
>> While most applications don't care one bit about st_ino returned from a
>> stat() call, the sad fact is that you'll get EOVERFLOW from stat32 if the
>> inode number is too big to fit in 32 bits, even if you just wanted to get
>> the file size.
> [snip]
>> Anyway, if you want to check your package(s) and maybe make them 64-bit-stat
>> safe, the perl script above might help. It's more than just
>> -DFILE_OFFSET_BITS=64, since you'll need to be sure not to overflow any
>> large values you get back from stat64 etc.
>>
>> Might be nice to get out ahead of this before, say, btrfs comes into wide
>> use. I don't know if there could be any more of a formal effort in this
>> direction?
>
>> p.s. here's a list of what was on my system that turned up hits:
> [snip list of several dozen packages that are affected]
>
>
> It would be useful to have a "backward compatibility" LD_PRELOAD shared
> library which intercepts the caller of stat32, and sets .st_ino to 0,
> without generating EOVERFLOW, whenever the actual inode number exceeds
> 32 bits. This would allow the *option* of continued operation
> (postponing the work of portability enhancements) for the vast majority
> of packages which do use stat() but do not inspect .st_ino.
Yep, that would make some sense as a workaround. FWIW, here's a systemtap
script which intercepts ext4 stat & bumps the inode nr past 2^32
(line numbers work on F18/kernel 3.7-8-ish at least)
probe kernel.statement("ext4_getattr@fs/ext4/inode.c+21")
{
$stat->ino = $stat->ino + 4294967295;
}
probe begin { log("starting probe") }
it demonstrates the failures pretty well:
# stat testfile | grep Inode
Device: fd01h/64769d Inode: 281242 Links: 1
# stap -g change-ino.stp &
[1] 5818
starting probe
# stat testfile | grep Inode
Device: fd01h/64769d Inode: 4295248537 Links: 1
# echo test | mail -s "does it work?" sand...@redhat.com
/etc/mail/sendmail.cf: line 0: cannot open: Value too large for defined data
type
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
