From: Vyacheslav Dubeyko <slava-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org>
To: Anthony Doggett
<Anthony2486-fDpYTK8McCxDP812hmKXO1pr/1R2p/CL@public.gmane.org>
Cc: linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: mkfs.nilfs2 -b 1024 -B 8192
Date: Thu, 14 Mar 2013 10:40:45 +0400 [thread overview]
Message-ID: <1363243245.2089.11.camel@slavad-ubuntu> (raw)
In-Reply-To: <20130313142726.GA3328-9gBkq9fxGAp+urZeOPWqwQ@public.gmane.org>
Hi Anthony,
On Wed, 2013-03-13 at 14:27 +0000, Anthony Doggett wrote:
> Hi Vyacheslav
>
> On Wed, Mar 13, 2013 at 12:25:01PM +0400, Vyacheslav Dubeyko wrote:
> > ...
> > Sorry, I don't clearly understand. Have you READ-ONLY FS issue only? Or
> > have you kernel panic? Could you confirm what situation you have?
>
> I did indeed forget to say what happens next! Future mounts would
> always print "NILFS warning: mounting fs with errors", so I'd always
> throw away that partition and restore from (tar-based) backups. I've
> pasted a little more detail on what the "ntest" filesystem looks like
> below. Looking at it, it looks as though the recovery might have
> removed all the errors (by rewinding far enough), but would that
> reliably be the case on a filesystem full of data? Even if the GC were
> running at the time?
>
As I understand, you had issue with remounting file system in Read-Only
mode (because of "NILFS error (device dm-3): nilfs_bmap_assign: broken
bmap (inode number=21)"), firstly. Then you tried unsuccessfully umount
file system in this state. I think that the message "NILFS warning
(device dm-3): nilfs_segctor_destroy: dirty file(s) after the final
construction" means that you didn't flush modified (or created) files
during umount. So, it means that you lost content of files. And,
finally, you can mount NILFS2 file system with presence of errors (I
think that it means some corruption of metadata). As a resume, this is
not good situation. Factually, this is a dangerous situation for user
data.
> > ...
> > The "flush kernel thread" issue is complex issue. The nature of this
> > issue begins from architectural solution of b-trees and DAT file. After
> > unsuccessful trying to elaborate simple fix I concluded that a clear
> > solution can be extents support implementation or adding special
> > metadata structure for GC operations. So, I think over about starting
> > implementation of it. But currently I hesitate about what can be a
> > better for start of implementation.
>
> Oh dear. I do hope that you find a simple solution! Where is the best
> place to find out more about the flush kernel thread issue? (Is there
> an issue tracker?)
>
You can get more details about the "flush kernel thread" issue in the
thread: http://www.spinics.net/lists/linux-nilfs/msg01476.html
With the best regards,
Vyacheslav Dubeyko.
> Hope that you do manage to reproduce the "broken bmap" issue easily
> enough. I shall have another go at reproducing the
> nilfs_btree_propagate issue reliably.
>
> Thanks,
> Anthony
>
> [ 811.211974] segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds
> [ 816.448465] nilfs_direct_assign: invalid pointer: 0
> [ 816.448487] NILFS error (device dm-3): nilfs_bmap_assign: broken bmap (inode number=21)
> [ 816.448494]
> [ 816.466784] Remounting filesystem read-only
>
> Then unmount (umount doesn't return: have to cancel it with Ctrl-C):
> [ 856.917108] nilfs_direct_assign: invalid pointer: 0
> [ 856.917123] NILFS error (device dm-3): nilfs_bmap_assign: broken bmap (inode number=21)
> [ 856.917128]
> [ 856.917294] nilfs_direct_assign: invalid pointer: 0
> [ 856.917305] NILFS error (device dm-3): nilfs_bmap_assign: broken bmap (inode number=21)
> [ 856.917309]
> [ 856.917473] nilfs_direct_assign: invalid pointer: 0
> [ 856.917483] NILFS error (device dm-3): nilfs_bmap_assign: broken bmap (inode number=21)
> [ 856.917488]
> [ 856.917660] nilfs_direct_assign: invalid pointer: 0
> [ 856.917670] NILFS error (device dm-3): nilfs_bmap_assign: broken bmap (inode number=21)
> [ 856.917674]
> [ 856.917689] NILFS warning (device dm-3): nilfs_segctor_destroy: dirty file(s) after the final construction
> [ 856.917694]
>
> Then mount once again:
> [ 974.586969] NILFS warning: mounting unchecked fs
> [ 975.088956] NILFS: recovery complete.
> [ 975.089763] segctord starting. Construction interval = 5 seconds, CP frequency < 30 seconds
> [ 975.090152] NILFS warning: mounting fs with errors
>
> > lscp /dev/mapper/unencrypted-ntest
> CNO DATE TIME MODE FLG NBLKINC ICNT
> 1 2013-03-13 11:20:59 cp - 12 2
> > lssu /dev/mapper/unencrypted-ntest
> SEGNUM DATE TIME STAT NBLOCKS
> 0 2013-03-13 11:20:59 ad- 12
> 1 ---------- --:--:-- ad- 0
> > sudo /sbin/nilfs-tune -l /dev/mapper/unencrypted-ntest
> nilfs-tune 2.1.3
> Filesystem volume name: (none)
> Filesystem UUID: 942d2231-5ea5-4430-96e3-4913917efddb
> Filesystem magic number: 0x3434
> Filesystem revision #: 2.0
> Filesystem features: (none)
> Filesystem state: valid,error
> Filesystem OS type: Linux
> Block size: 1024
> Filesystem created: Wed Mar 13 11:20:59 2013
> Last mount time: Wed Mar 13 11:23:44 2013
> Last write time: Wed Mar 13 11:27:33 2013
> Mount count: 2
> Maximum mount count: 50
> Reserve blocks uid: 0 (user root)
> Reserve blocks gid: 0 (group root)
> First inode: 11
> Inode size: 128
> DAT entry size: 32
> Checkpoint size: 192
> Segment usage size: 16
> Number of segments: 255
> Device size: 2147483648
> First data block: 4
> # of blocks per segment: 8192
> Reserved segments %: 5
> Last checkpoint #: 1
> Last block address: 4
> Last sequence #: 0
> Free blocks count: 2072576
> Commit interval: 0
> # of blks to create seg: 0
> CRC seed: 0x8a46fd5b
> CRC check sum: 0xd431caf2
> CRC check data size: 0x00000118
>
> > sudo dumpseg /dev/mapper/unencrypted-ntest 0
> segment: segnum = 0
> sequence number = 0, next segnum = 1
> partial segment: blocknr = 4, nblocks = 12
> creation time = 2013-03-13 11:20:59
> nfinfo = 5
> finfo
> ino = 2, cno = 1, nblocks = 1, ndatblk = 1
> vblocknr = 1, blkoff = 0, blocknr = 5
> finfo
> ino = 6, cno = 1, nblocks = 4, ndatblk = 4
> vblocknr = 2, blkoff = 0, blocknr = 6
> vblocknr = 3, blkoff = 1, blocknr = 7
> vblocknr = 4, blkoff = 2, blocknr = 8
> vblocknr = 5, blkoff = 3, blocknr = 9
> finfo
> ino = 4, cno = 1, nblocks = 1, ndatblk = 1
> vblocknr = 6, blkoff = 0, blocknr = 10
> finfo
> ino = 5, cno = 1, nblocks = 1, ndatblk = 1
> vblocknr = 7, blkoff = 0, blocknr = 11
> finfo
> ino = 3, cno = 1, nblocks = 3, ndatblk = 3
> blkoff = 0, blocknr = 12
> blkoff = 1, blocknr = 13
> blkoff = 2, blocknr = 14
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2013-03-14 6:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-13 7:14 mkfs.nilfs2 -b 1024 -B 8192 Anthony Doggett
[not found] ` <20130313071453.GA17072-P/DK4avwC2n/PtFMR13I2A@public.gmane.org>
2013-03-13 8:25 ` Vyacheslav Dubeyko
2013-03-13 14:27 ` Anthony Doggett
[not found] ` <20130313142726.GA3328-9gBkq9fxGAp+urZeOPWqwQ@public.gmane.org>
2013-03-14 6:40 ` Vyacheslav Dubeyko [this message]
2013-03-14 18:14 ` Vyacheslav Dubeyko
[not found] ` <424816AD-A79B-4F3D-A886-8D0CC735812B-yeENwD64cLxBDgjK7y7TUQ@public.gmane.org>
2013-04-09 21:08 ` Anthony Doggett
[not found] ` <20130409210827.GA3809-P/DK4avwC2n/PtFMR13I2A@public.gmane.org>
2013-04-10 6:19 ` Vyacheslav Dubeyko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1363243245.2089.11.camel@slavad-ubuntu \
--to=slava-yeenwd64clxbdgjk7y7tuq@public.gmane.org \
--cc=Anthony2486-fDpYTK8McCxDP812hmKXO1pr/1R2p/CL@public.gmane.org \
--cc=linux-nilfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.