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 self-
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 ma
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 f
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: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 ufs_rm
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 ba
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? Hav
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
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 "freebsd-questions-
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 filesyst
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
> 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 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 corrup
> 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(),
> 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.
___
fre
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 0x80a700e
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) a
> 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
> pare
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 ufs_rmdi
> 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 VOP_RM
El 27/07/2013 14:16, "David Noel" escribió:
>
> Yes
Post the stack trace of the core and maybe someone can help you.
>
> On 7/27/13, Fernando Apesteguía wrote:
> > El 27/07/2013 13:49, "David Noel" escribió:
> >>
> >> I had a strange experience on my laptop yesterday. I was deleting a
> >> dir
Yes
On 7/27/13, Fernando Apesteguía wrote:
> El 27/07/2013 13:49, "David Noel" 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 i
El 27/07/2013 13:49, "David Noel" 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 process several t
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 EXPECT
24 matches
Mail list logo