On Sun, 16 Dec 2001, Keith Owens wrote:
> On Sat, 15 Dec 2001 22:00:50 -0700,
> "D. Stimits" <stimits@xxxxxxxxxx> wrote:
> >Suresh Gopalakrishnan wrote:
> >> Hmm.. With 0777 mode argument, it just creates a huge file with the
> >> appropriate permissions (after umask).. same errors.. :(
> >>
> >> -rwxr-xr-x 1 gsuresh users 4294967274 Dec 15 22:14 /tmp/blah
> >>
> >> --suresh
> >
> >Interesting number, hex it is 0xFFFFFFEA. Hex 0x15 off from nice round
> >power of 2 minus 1, 0xF from turning over a 32 bit number. Not really
> >helpful, but I would expect in most cases it would be a number exactly
> >2^x - 1. Where do the last 0x15 bytes go? Is that some kind of overhead
> >granularity?
>
> This thread has migrated to linux-kernel, it is a kernel bug involving
> signed numbers being compared to unsigned. Hint, -EINVAL is -22,
> 0xFFFFFFEA. Not an XFS problem.
Thanks!
BTW, looks like a non-aligned buffer is not the only problem cause for
EINVAL - even with an aligned buffer, the code breaks if the write size is
not a multiple of 4K. I will follow it in the linux-kernel thread.
--suresh
|