The filesystem is XFS, and I used the recommended mkfs and mount options for Swift.<div><br></div><div>The file size seems to have no bearing on the issue, although I haven't tried really tiny files.   Bigfile3 is only 200K.</div>
<div><br></div><div>I'll try disabling fallocate...<br><br><div class="gmail_quote">On Mon, Oct 29, 2012 at 7:37 PM, Pete Zaitcev <span dir="ltr"><<a href="mailto:zaitcev@redhat.com" target="_blank">zaitcev@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, 29 Oct 2012 18:16:52 -0700<br>
Nathan Trueblood <<a href="mailto:nathan@truebloodllc.com">nathan@truebloodllc.com</a>> wrote:<br>
<br>
> Definitely NOT a problem with the filesystem, but something is causing the<br>
> object-server to think there is a problem with the filesystem.<br>
<br>
</div>If you are willing to go all-out, you can probably catch the<br>
error with strace, if it works on ARM. Failing that, find all places<br>
where 507 is generated and see if any exceptions are caught, by<br>
modifying the source, I'm afraid to say.<br>
<div class="im"><br>
> I suspect a bug in one of the underlying libraries.<br>
<br>
</div>That's a possibility. Or, it could be a kernel bug. You are using XFS,<br>
right? If it were something other than XFS or ext4, I would suspect<br>
ARM blowing over the 2GB barrier somewhere, since your object is<br>
called "bigfile3". As it is, you have little option than to divide<br>
the layers until you identify the one that's broken.<br>
<br>
BTW, make sure to disable the fallocate, since we're at it.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Pete<br>
</font></span></blockquote></div><br></div>