Re: A lot of NILFS: bad btree node messages (readonly fs)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jan 04, 2013 at 03:46:13PM +0300, Vyacheslav Dubeyko wrote:
> 
> On Jan 4, 2013, at 12:49 AM, Piotr Szymaniak wrote:
> > No, only checkpoints (just checked).
> 
> Ok. It means that snapshots don't play any role for the issue.

Yes, it seems so.


> So, the issue was occurred not because of using rsync. Am I correct? I
> simply remember that rsync was used in another report about this issue
> also.

Yes, rsync just gave me information where it had an i/o error.


> > But, thanks to rsync I got a (corupted?) file that causes the
> > problem.  It's some /var/tmp/kdecache-$USER/foo.kcache. copying this
> > file to another place ends with readonly.
> > 
> 
> So, maybe the nature of /var/tmp/kdecache-$USER/foo.kcache is a reason
> of the issue. It is a very interesting detail. Could you share more
> details about this file? I mean size, creation time, modification
> time, owner, rights and so on. Moreover, could you share more details
> about your hardware environment? I mean CPU and RAM details.

maszn ~ # file /var/tmp/kdecache-appe/plasma_theme_Transparent-sima84.kcache
gives me an i/o error and remounts ro.

maszn ~ # stat /var/tmp/kdecache-appe/plasma_theme_Transparent-sima84.kcache
  File: ‘/var/tmp/kdecache-appe/plasma_theme_Transparent-sima84.kcache’
  Size: 84213856        Blocks: 165144     IO Block: 4096   regular file
Device: 802h/2050d      Inode: 102230      Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1001/   appe)   Gid: (  414/   appe)
Access: 2012-11-14 16:15:01.377207479 +0100
Modify: 2012-11-14 16:15:01.377207479 +0100
Change: 2012-11-14 16:15:01.377207479 +0100

Intel Pentium Dual-Core E5400, 4GB RAM, nilfs2 is located on part of
Kingston SSD. It runs x86 Gentoo Linux with vanilla kernel (from
kernel.org) and I try to keep it up to date (3.6.8 right now, but I was
away for some time) and recent nilfs-utils from the portage tree (this
could also be considered as "up to date" or "up to upstream releases").


> I think that it can be very interesting to know about how this file is
> distributed on the volume. Could you get by means of dumpseg
> information about several last segments? I don't know how many it
> needs for understanding but maybe about 10 can be enough for the
> beginning.

The file is pretty old so last 10 segments won't solve the issue, right?

Piotr Szymaniak.
-- 
 Natezyl sluch. Nic poza odglosami owadow z dziedzinca i naszeptywaniem
spryskiwaczy trawnika. Nic poza miarowym kapaniem z kranu w lazience.
 To bylo niczym zycie, skapujace kropla po kropli. K a p, k a p, k a p,
wszystko w kanal.
  -- Graham Masterton, "The Burning"

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux Filesystem Development]     [Linux BTRFS]     [Linux CIFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux