* [9fans] Corrupted meta data @ 2008-07-16 21:25 Brian L. Stuart 2008-07-16 22:01 ` Russ Cox 0 siblings, 1 reply; 6+ messages in thread From: Brian L. Stuart @ 2008-07-16 21:25 UTC (permalink / raw) To: 9fans How do you remove a file with corrupted meta data? I was in 9vx and trying to recompile a kernel so I could get a boot file with the local method and it locked. After I killed 9vx and started it up again, I can't mk because main.8 has corrupted meta data. check in fossilcons reports it, but apparently can't fix it. I also can't remove it in fossilcons any more than I can from an rc prompt. Any magic? Thanks, BLS ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] Corrupted meta data 2008-07-16 21:25 [9fans] Corrupted meta data Brian L. Stuart @ 2008-07-16 22:01 ` Russ Cox 2008-07-17 15:39 ` Brian L. Stuart 0 siblings, 1 reply; 6+ messages in thread From: Russ Cox @ 2008-07-16 22:01 UTC (permalink / raw) To: 9fans > How do you remove a file with corrupted meta data? > I was in 9vx and trying to recompile a kernel so > I could get a boot file with the local method > and it locked. After I killed 9vx and started it > up again, I can't mk because main.8 has corrupted > meta data. check in fossilcons reports it, but > apparently can't fix it. I also can't remove > it in fossilcons any more than I can from an rc > prompt. > > Any magic? Can you clri the file from fossilcons? Russ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] Corrupted meta data 2008-07-16 22:01 ` Russ Cox @ 2008-07-17 15:39 ` Brian L. Stuart 2008-07-17 16:20 ` Russ Cox 0 siblings, 1 reply; 6+ messages in thread From: Brian L. Stuart @ 2008-07-17 15:39 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > Can you clri the file from fossilcons? Unfortunately, that just reports the corrupted meta data too. Interestingly, when I started it up this morning, the check didn't report an error with it. But then after trying to access it, check now reports: error: could not unpack meta block: /active/sys/src/9/pc[3]: corrupted meta data What does the 3 refer to? The 3rd block of the pc directory, maybe? The pc directory itself seems fine. I can see everything else there. main.8 doesn't show up in an lc. If my current directory is elsewhere and I try to ls -l /n/fossil/sys/src/9/pc/main.8, it comes up as not existing. But if my current directory is /n/fossil/sys/src/9/pc, then I get the corrupted meta data error. I haven't changed anything in that directory, so in principle, I guess i could blow away the directory (clri if necessary) and copy it all back from a venti snapshot. But before I do that, I'd like to see if a more direct recovery is possible. BTW, I had it lock up again this morning. I've noticed that when it does, it uses 100% of the CPU. It's acting like it's stuck in a spin lock. I can't say for sure, so this may be a red herring, but it has seemed that every time it's locked up, it's been when doing I/O to the sdloop device. Thanks, BLS ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] Corrupted meta data 2008-07-17 15:39 ` Brian L. Stuart @ 2008-07-17 16:20 ` Russ Cox 2008-07-17 17:56 ` Brian L. Stuart 2008-07-17 18:40 ` Brian L. Stuart 0 siblings, 2 replies; 6+ messages in thread From: Russ Cox @ 2008-07-17 16:20 UTC (permalink / raw) To: 9fans > error: could not unpack meta block: /active/sys/src/9/pc[3]: corrupted meta data > What does the 3 refer to? The 3rd block of the pc directory, > maybe? Yes. Your best bet is probably to clri /active/sys/src/9/pc and not look back. > BTW, I had it lock up again this morning. I've noticed that > when it does, it uses 100% of the CPU. It's acting like > it's stuck in a spin lock. I can't say for sure, so this > may be a red herring, but it has seemed that every time > it's locked up, it's been when doing I/O to the sdloop > device. Locks on Plan 9 don't use 100% of the cpu. Even spin locks start sleeping after enough contention. It's more likely in a bad loop somewhere. Is it repeatedly doing I/O during the 100% cpu? Russ ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] Corrupted meta data 2008-07-17 16:20 ` Russ Cox @ 2008-07-17 17:56 ` Brian L. Stuart 2008-07-17 18:40 ` Brian L. Stuart 1 sibling, 0 replies; 6+ messages in thread From: Brian L. Stuart @ 2008-07-17 17:56 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > Your best bet is probably to clri /active/sys/src/9/pc > and not look back. clri /active/sys/src/9/pc no_lb_mode = 1 ; It is happy now. > It's more likely in a bad loop somewhere. > Is it repeatedly doing I/O during the 100% cpu? I don't honestly know. Next time it happens, I'll check and see. BLS ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [9fans] Corrupted meta data 2008-07-17 16:20 ` Russ Cox 2008-07-17 17:56 ` Brian L. Stuart @ 2008-07-17 18:40 ` Brian L. Stuart 1 sibling, 0 replies; 6+ messages in thread From: Brian L. Stuart @ 2008-07-17 18:40 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > It's more likely in a bad loop somewhere. > Is it repeatedly doing I/O during the 100% cpu? It just locked again. Here's what I'm seeing. In top, the first thread is using 100% of the CPU and all the other threads are in the S state with no run time. I don't see any indications either in vmstat or in load from p9p that there is any I/O going on to speak of or an unusual number of system calls being issued. If there's anything else I can check, let me know. Thanks, BLS ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2008-07-17 18:40 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-07-16 21:25 [9fans] Corrupted meta data Brian L. Stuart 2008-07-16 22:01 ` Russ Cox 2008-07-17 15:39 ` Brian L. Stuart 2008-07-17 16:20 ` Russ Cox 2008-07-17 17:56 ` Brian L. Stuart 2008-07-17 18:40 ` Brian L. Stuart
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).