On Tue, 22 Oct 2013 18:20:19 +0200 David Sterba <dste...@suse.cz> wrote:
> > However, it's not possible to work with this system via SSH, because > > these keep popping up few times every minute: > > Probably only some of the files that get accessed during ssh login is > corrupted, but the scrub does not get far enough to let you know the > filenames. You can try to look into 'lsof' output which files are open > by sshd or it's children. It's not the case. Files in btrfs mount are not accessed in any way - the scrub was started after restart, and there is no way anything on this system can accidentally access data there. This is further confirmed by lsof output. > > kernel:[22219.117012] BUG: soft lockup - CPU#2 stuck for 23s! > > [btrfs:5673] kernel:[22247.100515] BUG: soft lockup - CPU#0 stuck > > for 23s! [btrfs:5674] kernel:[22247.100519] BUG: soft lockup - > > CPU#2 stuck for 23s! [btrfs:5673] > > Cpus 0 and 2 are stuck and every other attempt to access the broken > files will pin another cpu. Scrub was running for some time; after scrubbung about 2.8 TB, the system was so slow, that it was barely possible to launch any command. "reboot" issued via ssh took ~8 hours to execute. A new scrub started after the reboot immediately begins to show "BUG: soft lockup - CPU#2 stuck for 23s!". Anyway, it is RAID-1 - I would expect the scrub to either correct corrupt data (from a copy on the other disk), or mark it as invalid (both copies corrupt), but not "nearly hang" the server, or? -- Tomasz Chmielewski http://wpkg.org -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
