This fixes only symptom, not illness.
This check represent what code think about filesystem layout.
On what actually kind of UFS system did you test this patch?
When I sometime ago fixed similar issue for openstep ufs,
actully this was darwin's ufs which has the same layout,
I just set
This fixes only symptom, not illness.
This check represent what code think about filesystem layout.
On what actually kind of UFS system did you test this patch?
When I sometime ago fixed similar issue for openstep ufs,
actully this was darwin's ufs which has the same layout,
I just set
On Tue, Nov 20, 2007 at 12:29:03PM -0800, Dave Bailey wrote:
> This problem has been around since kernel 2.6.16, and I see it in
> 2.6.23.1-10.fc7. It occurs in the ufs_check_page function of ufs/dir.c
> at the Espan test, which seems unnecessary for NextStep/OpenStep
> files systems. The
> This problem has been around since kernel 2.6.16, and I see it in
> 2.6.23.1-10.fc7. It occurs in the ufs_check_page function of ufs/dir.c
> at the Espan test, which seems unnecessary for NextStep/OpenStep
> files systems. The following patch preserves the test for other file
> systems and makes
This problem has been around since kernel 2.6.16, and I see it in
2.6.23.1-10.fc7. It occurs in the ufs_check_page function of ufs/dir.c
at the Espan test, which seems unnecessary for NextStep/OpenStep
files systems. The following patch preserves the test for other file
systems and makes the
On Tue, Nov 20, 2007 at 12:29:03PM -0800, Dave Bailey wrote:
This problem has been around since kernel 2.6.16, and I see it in
2.6.23.1-10.fc7. It occurs in the ufs_check_page function of ufs/dir.c
at the Espan test, which seems unnecessary for NextStep/OpenStep
files systems. The following
This problem has been around since kernel 2.6.16, and I see it in
2.6.23.1-10.fc7. It occurs in the ufs_check_page function of ufs/dir.c
at the Espan test, which seems unnecessary for NextStep/OpenStep
files systems. The following patch preserves the test for other file
systems and makes the
This problem has been around since kernel 2.6.16, and I see it in
2.6.23.1-10.fc7. It occurs in the ufs_check_page function of ufs/dir.c
at the Espan test, which seems unnecessary for NextStep/OpenStep
files systems. The following patch preserves the test for other file
systems and makes the
On Mon, Apr 16, 2007 at 11:32:04AM +0400, Evgeniy Dushistov wrote:
> >The error also happens in 2.6.19, same as in 2.6.18.
> >I extracted this from syslog:
> >Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0):
> >ufs_check_page: bad entry
>
> Is this happened also with this patch:
>
On Mon, Apr 16, 2007 at 11:32:04AM +0400, Evgeniy Dushistov wrote:
The error also happens in 2.6.19, same as in 2.6.18.
I extracted this from syslog:
Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0):
ufs_check_page: bad entry
Is this happened also with this patch:
On Mon, Apr 16, 2007 at 05:04:22PM +0100, Dale Amon wrote:
> On Mon, Apr 16, 2007 at 11:32:04AM +0400, Evgeniy Dushistov wrote:
> > >The error also happens in 2.6.19, same as in 2.6.18.
> > >I extracted this from syslog:
> > >Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0):
> >
On Mon, Apr 16, 2007 at 11:32:04AM +0400, Evgeniy Dushistov wrote:
> >The error also happens in 2.6.19, same as in 2.6.18.
> >I extracted this from syslog:
> >Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0):
> >ufs_check_page: bad entry
>
> Is this happened also with this patch:
>
>The error also happens in 2.6.19, same as in 2.6.18.
>I extracted this from syslog:
>Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0):
>ufs_check_page: bad entry
Is this happened also with this patch:
http://lkml.org/lkml/diff/2007/2/5/75/1
?
--
/Evgeniy
-
To unsubscribe from this
The error also happens in 2.6.19, same as in 2.6.18.
I extracted this from syslog:
Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0):
ufs_check_page: bad entry
Is this happened also with this patch:
http://lkml.org/lkml/diff/2007/2/5/75/1
?
--
/Evgeniy
-
To unsubscribe from this list:
On Mon, Apr 16, 2007 at 11:32:04AM +0400, Evgeniy Dushistov wrote:
The error also happens in 2.6.19, same as in 2.6.18.
I extracted this from syslog:
Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0):
ufs_check_page: bad entry
Is this happened also with this patch:
On Mon, Apr 16, 2007 at 05:04:22PM +0100, Dale Amon wrote:
On Mon, Apr 16, 2007 at 11:32:04AM +0400, Evgeniy Dushistov wrote:
The error also happens in 2.6.19, same as in 2.6.18.
I extracted this from syslog:
Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0):
ufs_check_page: bad
The error also happens in 2.6.19, same as in 2.6.18. I
extracted this from syslog:
Apr 17 00:14:08 kdev kernel: loop: loaded (max 8 devices)
Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0): ufs_check_page: bad
entry in directory #2: directory entry across blocks - offset=356,
The error also happens in 2.6.19, same as in 2.6.18. I
extracted this from syslog:
Apr 17 00:14:08 kdev kernel: loop: loaded (max 8 devices)
Apr 17 00:14:15 kdev kernel: UFS-fs error (device loop0): ufs_check_page: bad
entry in directory #2: directory entry across blocks - offset=356,
I recently noticed that I can no longer read my
images of NeXTstep floppies on certain machines.
All are running an up to date etch distribution
but the difference between where I can read or not
read seems to be the linux version. On a 2.6.18
machine:
# mount -t ufs -o ro,ufstype=nextstep,loop
I recently noticed that I can no longer read my
images of NeXTstep floppies on certain machines.
All are running an up to date etch distribution
but the difference between where I can read or not
read seems to be the linux version. On a 2.6.18
machine:
# mount -t ufs -o ro,ufstype=nextstep,loop
20 matches
Mail list logo
