Hi Anton,
On Wed, 2013-05-22 at 22:33 +0200, Anton Eliasson wrote:
> Greetings!
> It pains me to report that my /home filesystem broke down today. My
> system is running Arch Linux 64-bit. The filesystem resides on a Crucial
> M4 256 GB SSD, on top of a LVM2 volume. The drive and filesystem are
> both around six months old. Partition table and error log excerpts are
> at the bottom of this e-mail. Full logs are available upon request.
>
> I am providing this information as a bug report. I have no reason to
> suspect the hardware but I cannot exclude it either. If you (the
> developers) are interested in troubleshooting this for prosperity, I can
> be your hands and run whatever tools are required. If not, I'll reformat
> the filesystem, restore the data from backup and forget that this happened.
>
> In case the formatting gets mangled, this e-mail is also available at
> What happened today, in chronological order:
>
> ~18:00
> ======
> I am troubleshooting some issues that turn out to be caused by a wrongly
> configured system clock. The RTC (hardware clock) is set to local time
> (UTC+2) but the OS is configured to treat the RTC as UTC. This is
> because it was set to UTC previously, but then I reinstalled Windows
> which promptly reset it to local time.
>
> This set the mtime of some files in both / and /home to dates in the
> future. When I discovered this, I `touch`ed all affected files (`touch
> now; sudo find / /home -xdev -newer now -exec touch {} \;`) to reset
> their mtime and rebooted the system. I do not know if this is relevant;
> if not, it makes reading the log files more fun.
>
> I then launch my command line backup program "bup", Firefox and some
> other apps.
>
> ~18:50-19:00
> ============
> Firefox freezes. The system keeps running but I can't launch new
> programs. It looked like all I/O broke down. However, bup kept running.
> I left the computer alone for perhaps 30-60 min.
>
So, as I understand, a reproducing path is:
(1) set mtime of some files in the future;
(2) touch all affected files;
(3) reboot the system;
(4) launch backup program "bup", Firefox and some other apps.
I think that it makes sense to try this reproducing path. But we had
reports about the issue with likewise symptoms
(nilfs_bmap_lookup_contig: broken bmap) for the case of 4 KB block size
from other users. Unfortunately, I can't reproduce such issue for the
case of 4 KB blocks size earlier. As I feel the clear reproducing path
is crucial for this issue.
I understand that it can be hard to reproduce the issue again. But,
anyway, have you opportunity to try to reproduce the issue on another
NILFS2 partition on your side?
Anyway, I am going to reproduce the issue by this reproducing path on my
side.
> ~20:00
> ======
> When I came back, bup hade frozen (/var/log/messages at 18:53:31).[1] I
> restart X by pressing Alt+SysRq+K (/var/log/messages at 20:06:33) and
> return to the login screen. The system freezes during login though,
> probably because /home had probably been mounted read only). So I reboot
> using Alt+SysRq+REISUB (/var/log/messages at 20:07:05). I noticed some
> I/O errors during shutdown.
>
> After the reboot there are no immediate signs of disaster. I launch bup
> again. Some time later, /home remounts as read only. I notice that bup
> has reported I/O errors while reading some files in /home.[2] dmesg and
> /var/log/kern.log contains errors mentioning "bad btree node" and
> "nilfs_bmap_lookup_contig: broken bmap".[3]
>
Now we have patch for overcome the freezing of system after such issue:
http://www.mail-archive.com/linux-nilfs@xxxxxxxxxxxxxxx/msg01614.html.
With the best regards,
Vyacheslav Dubeyko.
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
