From: Bret Towe on
I recently attempted upgrading from 2.6.31.6 to 2.6.32.8 on a local server
that runs several filesystems and when trying to move or copy or create a file
on a reiserfs system that was sitting on lvm over raid5(not sure if
that matters)
I would get mv or cp to return Invalid Argument and not doing anything
moving files from xfs to xfs worked fine tho

for now I went back to .31.6 I'm willing to test any patches required
any config info or what not let me know and I'll dig it up
dmesg was clean
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on
On Sunday 14 February 2010, Bret Towe wrote:
> I recently attempted upgrading from 2.6.31.6 to 2.6.32.8 on a local server
> that runs several filesystems and when trying to move or copy or create a file
> on a reiserfs system that was sitting on lvm over raid5(not sure if
> that matters)
> I would get mv or cp to return Invalid Argument and not doing anything
> moving files from xfs to xfs worked fine tho
>
> for now I went back to .31.6 I'm willing to test any patches required
> any config info or what not let me know and I'll dig it up
> dmesg was clean

I have created the Bugzilla entry at http://bugzilla.kernel.org/show_bug.cgi?id=15309
for your report.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Christian Kujau on
On Sun, 14 Feb 2010 at 10:23, Bret Towe wrote:
> I recently attempted upgrading from 2.6.31.6 to 2.6.32.8 on a local server
> that runs several filesystems and when trying to move or copy or create a file
> on a reiserfs system that was sitting on lvm over raid5(not sure if
> that matters)
> I would get mv or cp to return Invalid Argument and not doing anything
> moving files from xfs to xfs worked fine tho

I'm running 2.6.32 (and now 2.6.33) with reiserfs filesystems too and
cannot reproduce what you're seeing. Can you run mv/cp through strace and
provide the output? Also, if you can: maybe setting REISERFS_CHECK in your
kernel config might reveal something useful.

Is this reproducible with 2.6.33-rcX as well? If so, I'd recommend to try
again with plain 2.6.32 and if it's still there, I see no other way to
narrow it down but with a git bisection (man git-bisect).

Christian.
--
BOFH excuse #216:

What office are you in? Oh, that one. Did you know that your building was built over the universities first nuclear research site? And wow, aren't you the lucky one, your office is right over where the core is buried!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Bret Towe on
On Sun, Feb 14, 2010 at 10:45 PM, Bret Towe <magnade(a)gmail.com> wrote:
> On Sun, Feb 14, 2010 at 10:39 PM, Christian Kujau <lists(a)nerdbynature.de> wrote:
>> On Sun, 14 Feb 2010 at 10:23, Bret Towe wrote:
>>> I recently attempted upgrading from 2.6.31.6 to 2.6.32.8 on a local server
>>> that runs several filesystems and when trying to move or copy or create a file
>>> on a reiserfs system that was sitting on lvm over raid5(not sure if
>>> that matters)
>>> I would get mv or cp to return Invalid Argument and not doing anything
>>> moving files from xfs to xfs worked fine tho
>>
>> I'm running 2.6.32 (and now 2.6.33) with reiserfs filesystems too and
>> cannot reproduce what you're seeing. Can you run mv/cp through strace and
>> provide the output? Also, if you can: maybe setting REISERFS_CHECK in your
>> kernel config might reveal something useful.
>>
>> Is this reproducible with 2.6.33-rcX as well? If so, I'd recommend to try
>> again with plain 2.6.32 and if it's still there, I see no other way to
>> narrow it down but with a git bisection (man git-bisect).
>
> I forgot to note that file operations on the reiserfs partitions
> worked fine inside themselves
>
> I guess I will see about running a few other kernels then over next
> few days as time permits
> first I will try is the reiserfs_check option tho then revert to .32
> and go from there
>

and I will also forget to hit reply all in the time being
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Bret Towe on
On Sun, Feb 14, 2010 at 10:39 PM, Christian Kujau <lists(a)nerdbynature.de> wrote:
> On Sun, 14 Feb 2010 at 10:23, Bret Towe wrote:
>> I recently attempted upgrading from 2.6.31.6 to 2.6.32.8 on a local server
>> that runs several filesystems and when trying to move or copy or create a file
>> on a reiserfs system that was sitting on lvm over raid5(not sure if
>> that matters)
>> I would get mv or cp to return Invalid Argument and not doing anything
>> moving files from xfs to xfs worked fine tho
>
> I'm running 2.6.32 (and now 2.6.33) with reiserfs filesystems too and
> cannot reproduce what you're seeing. Can you run mv/cp through strace and
> provide the output? Also, if you can: maybe setting REISERFS_CHECK in your
> kernel config might reveal something useful.
>
> Is this reproducible with 2.6.33-rcX as well? If so, I'd recommend to try
> again with plain 2.6.32 and if it's still there, I see no other way to
> narrow it down but with a git bisection (man git-bisect).
>

ok attached is strace log of cp on 2.6.32.9
the reiserfs_check doesn't spew anything that I could see
and 2.6.33-rc also didn't help

now I've had a hd drop out of raid (running checks on it atm)
and seen some other issues that make me wonder about the quality of the hardware
the 2.6.32.9 was compiled on a different computer to eliminate that
possibility but didn't help alas
I intend to replace this computers motherboard if I still see the
issue I will start doing bisect
at that point but the issue might go away as some configuration I have
will change (dropping the raid5)

time frame will be probably a few weeks at best