On 28/07/2013 06:54, Polytropon wrote:
And here, kids, you can see the strength of open source
operating system: You can see _why_ something happens. :-)
Too true!
On Sat, 27 Jul 2013 20:35:09 +0100, Frank Leonhardt wrote:
On 27/07/2013 19:57, David Noel wrote:
So the system panics in
Ok folks, thanks again for all the help. Using the feedback I
submitted a PR (#180894) --
http://www.freebsd.org/cgi/query-pr.cgi?pr=180894. I also submitted a
follow-up to it with Frank's code and notes. What next? I don't really
know what happens from here, but I'm guessing/hoping that someone's
On 28/07/2013 06:38, David Noel wrote:
Ok folks, thanks again for all the help. Using the feedback I
submitted a PR (#180894) --
http://www.freebsd.org/cgi/query-pr.cgi?pr=180894. I also submitted a
follow-up to it with Frank's code and notes. What next? I don't really
know what happens from
On Sun, 28 Jul 2013, Frank Leonhardt wrote:
So it boils down to:
a) Leave is is, as it can detect when the kernel has trashed its vnode table;
or
b) It's probably caused by expected FS corruption, so handle it gracefully.
It would be good to log a system error message like filesystem may
On 07/27/13 21:12, cpghost wrote:
A more robust file system would halt all processes, and perform
an in-kernel fsck on the filesystem and its internal (in-memory)
structures to repair the damage... and THEN resume the processes.
However, this is a major project, and we don't have a
I had a strange experience on my laptop yesterday. I was deleting a
directory and the system crashed. It spat out a message along the
lines of ufs_dirrem bad link count 2 on parent. I thought it was so
strange I repeated the process several times, and each time it
crashed. Is this behavior
El 27/07/2013 13:49, David Noel david.i.n...@gmail.com escribió:
I had a strange experience on my laptop yesterday. I was deleting a
directory and the system crashed. It spat out a message along the
lines of ufs_dirrem bad link count 2 on parent. I thought it was so
strange I repeated the
Yes
On 7/27/13, Fernando Apesteguía fernando.apesteg...@gmail.com wrote:
El 27/07/2013 13:49, David Noel david.i.n...@gmail.com escribió:
I had a strange experience on my laptop yesterday. I was deleting a
directory and the system crashed. It spat out a message along the
lines of ufs_dirrem
El 27/07/2013 14:16, David Noel david.i.n...@gmail.com escribió:
Yes
Post the stack trace of the core and maybe someone can help you.
On 7/27/13, Fernando Apesteguía fernando.apesteg...@gmail.com wrote:
El 27/07/2013 13:49, David Noel david.i.n...@gmail.com escribió:
I had a strange
Post the stack trace of the core and maybe someone can help you.
panic: ufs_dirrem: Bad link count 2 on parent
cpuid = 0
KDB: stack backtrace:
#0 0x808680fe at kdb_backtrace+0x5e
#1 0x80832cb7 at panic+0x187
#2 0x80a700e3 at ufs_rmdir+0x1c3
#3 0x80b7d484 at
On 27/07/2013 13:58, David Noel wrote:
Post the stack trace of the core and maybe someone can help you.
panic: ufs_dirrem: Bad link count 2 on parent
cpuid = 0
KDB: stack backtrace:
#0 0x808680fe at kdb_backtrace+0x5e
#1 0x80832cb7 at panic+0x187
#2 0x80a700e3 at
I'm taking a guess here - the effective link count when it came to
removing the parent directory was only two and it should have been three
or more. This gets sanity checked this before proceeding, and panics if
it is not. Why an effective link count of three? We're talking about the
parent
On 07/27/2013 11:30, David Noel wrote:
-- it's a laptop and I've inadvertently run the battery down to
nothing a few times in the past. All the same, it was a very strange
experience. I would not have expected a kernel panic from a simple rm
-rf!
You may want to look into running fsck(8) and
On 07/27/13 14:58, David Noel wrote:
Post the stack trace of the core and maybe someone can help you.
panic: ufs_dirrem: Bad link count 2 on parent
cpuid = 0
KDB: stack backtrace:
#0 0x808680fe at kdb_backtrace+0x5e
#1 0x80832cb7 at panic+0x187
#2 0x80a700e3 at
You may want to look into running fsck(8) and its myriad of options
fsck did the trick
Also make sure you have soft updates enabled on your filesystem and
preferably journaled soft updates
..pretty sure I do but I'll double check, thanks.
___
So the system panics in ufs_rmdir(). Maybe the filesystem is
corrupt? Have you tried to fsck(8) it manually?
fsck worked, though I had to boot from a USB image because I couldn't
get into single user.. for some odd reason.
Even if the filesystem is corrupt, ufs_rmdir() shouldn't
panic(),
On 27/07/2013 19:57, David Noel wrote:
So the system panics in ufs_rmdir(). Maybe the filesystem is
corrupt? Have you tried to fsck(8) it manually?
fsck worked, though I had to boot from a USB image because I couldn't
get into single user.. for some odd reason.
Even if the filesystem is
I was going to raise an issue when the discussion had died down to a
concensus. I also don't think it's reasonable for the kernel to bomb
when it encounters corruption on a disk.
If you want to patch it yourself, edit sys/ufs/ufs/ufs_vnops.c at around
line 2791 change:
if
On 27/07/2013 20:38, David Noel wrote:
I was going to raise an issue when the discussion had died down to a
concensus. I also don't think it's reasonable for the kernel to bomb
when it encounters corruption on a disk.
If you want to patch it yourself, edit sys/ufs/ufs/ufs_vnops.c at around
line
On 07/27/13 20:57, David Noel wrote:
So the system panics in ufs_rmdir(). Maybe the filesystem is
corrupt? Have you tried to fsck(8) it manually?
fsck worked, though I had to boot from a USB image because I couldn't
get into single user.. for some odd reason.
Even if the filesystem is
Yes. It'd be nice if UFS/FFS would just downgrade things to read-only
and not panic.
-Adrian
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to
On Sat, 27 Jul 2013 13:57:31 -0500, David Noel wrote:
So the system panics in ufs_rmdir(). Maybe the filesystem is
corrupt? Have you tried to fsck(8) it manually?
fsck worked, though I had to boot from a USB image because I couldn't
get into single user.. for some odd reason.
From your
And here, kids, you can see the strength of open source
operating system: You can see _why_ something happens. :-)
On Sat, 27 Jul 2013 20:35:09 +0100, Frank Leonhardt wrote:
On 27/07/2013 19:57, David Noel wrote:
So the system panics in ufs_rmdir(). Maybe the filesystem is
corrupt? Have you
On Sat, 27 Jul 2013 14:57:07 -0700, Adrian Chadd wrote:
Yes. It'd be nice if UFS/FFS would just downgrade things to read-only
and not panic.
That would be possible, but it would confuse programs and users.
It's not that you could walk up to the disk drive and flip the
write protect switch
24 matches
Mail list logo
