All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chao Yu <chao2.yu@samsung.com>
To: 'Jaegeuk Kim' <jaegeuk@kernel.org>,
	'David Gnedt' <david.gnedt@davizone.at>,
	'Matthias Prager' <linux@matthiasprager.de>
Cc: linux-f2fs-devel@lists.sourceforge.net
Subject: Re: f2fs bug: Unable to mount big volumes in kernel 4.5
Date: Mon, 21 Mar 2016 11:18:35 +0800	[thread overview]
Message-ID: <00d401d18320$75f94e80$61ebeb80$@samsung.com> (raw)
In-Reply-To: <20160320224654.GB4752@jaegeuk.hsd1.ca.comcast.net>

Hi all,

> -----Original Message-----
> From: Jaegeuk Kim [mailto:jaegeuk@kernel.org]
> Sent: Monday, March 21, 2016 6:47 AM
> To: David Gnedt
> Cc: Chao Yu
> Subject: Re: f2fs bug: Unable to mount big volumes in kernel 4.5
> 
> Hello,
> 
> As you pointed out, it seems there is a bug in sanity check routine, which
> doesn't cover the large section case.

Actually, there is a bug in f2fs-tools 1.6.0, it will trigger sanity check failure
in f2fs kernel module since in mkfs.f2fs we will align segment_count and
segment_count_main with different size if parameter -s or -z is configured larger
than 1.

Following commit in dev branch of f2fs-tools has fixed this issue, could you test this
patch firstly?
("mkfs.f2fs: set segment_count in super block correctly")

Thanks,

> 
> Could you test the attached patch?
> 
> Thanks,
> 
> On Sun, Mar 20, 2016 at 04:53:10PM +0100, David Gnedt wrote:
> > Hello,
> >
> > I have a problem with mounting a very big f2fs volume (8TB Seagate SMR drive) in
> > kernel 4.5. It works without any problems in 4.4.6, but with 4.5 I get errors
> > during mount (see attached file smr_log.txt).
> >
> > I have created the volume with f2fs-tools 1.6.0 and also a fsck works without
> > any problems (see attached file smr_fsck.txt).
> >
> > I suspect the following commit to be the cause:
> >
> > commit 9a59b62fd88196844cee5fff851bee2cfd7afb6e
> > f2fs: do more integrity verification for superblock
> >
> >
> https://git.kernel.org/cgit/linux/kernel/git/jaegeuk/f2fs.git/commit/fs/f2fs/super.c?id=9a
> 59b62fd88196844cee5fff851bee2cfd7afb6e
> >
> > I haven't had time to dig deeper, but my guess is that the volume is too big, so
> > that the 32bit integers overflow during the new check routine
> > sanity_check_area_boundary().
> >
> > Please let me know, if you need any more information. F2fs is currently the only
> > filesystem that really works on those SMR drives, therefore it is an important
> > issue to me.
> >
> > Best regards,
> > David Gnedt
> 
> > [437136.843299] F2FS-fs (dm-7): Wrong MAIN_AREA boundary, start(4063232) end(1953505792)
> blocks(1949433856)
> > [437136.843302] F2FS-fs (dm-7): Can't find valid F2FS filesystem in 1th superblock
> > [437136.843418] F2FS-fs (dm-7): Wrong MAIN_AREA boundary, start(4063232) end(1953505792)
> blocks(1949433856)
> > [437136.843419] F2FS-fs (dm-7): Can't find valid F2FS filesystem in 2th superblock
> > [437136.843420] F2FS-fs (dm-7): Wrong MAIN_AREA boundary, start(4063232) end(1953505792)
> blocks(1949433856)
> > [437136.843421] F2FS-fs (dm-7): Can't find valid F2FS filesystem in 1th superblock
> > [437136.843422] F2FS-fs (dm-7): Wrong MAIN_AREA boundary, start(4063232) end(1953505792)
> blocks(1949433856)
> > [437136.843422] F2FS-fs (dm-7): Can't find valid F2FS filesystem in 2th superblock
> 
> > Info: sector size = 512
> > Info: total sectors = 15628046336 (7630882 MB)
> > Info: MKFS version
> >   "Linux version 4.4.0-040400-generic (kernel@gomeisa) (gcc version 5.2.1 20151010 (Ubuntu
> 5.2.1-22ubuntu2) ) #201601101930 SMP Mon Jan 11 00:32:41 UTC 2016"
> > Info: FSCK version
> >   from "Linux version 4.4.0-040400-generic (kernel@gomeisa) (gcc version 5.2.1 20151010
> (Ubuntu 5.2.1-22ubuntu2) ) #201601101930 SMP Mon Jan 11 00:32:41 UTC 2016"
> >     to "Linux version 4.5.0-040500-generic (kernel@tangerine) (gcc version 5.2.1 20151010
> (Ubuntu 5.2.1-22ubuntu2) ) #201603140130 SMP Mon Mar 14 05:32:22 UTC 2016"
> > Info: superblock features = 0 :
> > Info: superblock encrypt level = 0, salt = 00000000000000000000000000000000
> > Info: total FS sectors = 15628046336 (7630882 MB)
> > Info: CKPT version = 122a
> > Info: checkpoint state = 1 :  unmount
> >
> > [FSCK] Unreachable nat entries                        [Ok..] [0x0]
> > [FSCK] SIT valid block bitmap checking                [Ok..]
> > [FSCK] Hard link checking for regular file            [Ok..] [0x0]
> > [FSCK] valid_block_count matching with CP             [Ok..] [0x57cea239]
> > [FSCK] valid_node_count matcing with CP (de lookup)   [Ok..] [0x61b3bd]
> > [FSCK] valid_node_count matcing with CP (nat lookup)  [Ok..] [0x61b3bd]
> > [FSCK] valid_inode_count matched with CP              [Ok..] [0x4c0a61]
> > [FSCK] free segment_count matched with CP             [Ok..] [0xe31ac]
> > [FSCK] next block offset is free                      [Ok..]
> > [FSCK] fixing SIT types
> > [FSCK] other corrupted bugs                           [Ok..]
> >
> > Done.



------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140

       reply	other threads:[~2016-03-21  3:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <56EEC766.2030503@davizone.at>
     [not found] ` <20160320224654.GB4752@jaegeuk.hsd1.ca.comcast.net>
2016-03-21  3:18   ` Chao Yu [this message]
2016-03-21  9:58     ` f2fs bug: Unable to mount big volumes in kernel 4.5 Matthias Prager
2016-03-21 15:57       ` Jaegeuk Kim
2016-03-21 10:30     ` Marc Lehmann
2016-03-21 16:03       ` Jaegeuk Kim
2016-03-22  3:37         ` Chao Yu
2016-03-22 20:05           ` Jaegeuk Kim
2016-03-21 20:58     ` David Gnedt
2016-03-21 22:56       ` Matthias Prager
2016-03-22  8:16         ` Chao Yu
     [not found]         ` <20160322203613.GA14498@jaegeuk.gateway>
2016-03-22 20:50           ` Matthias Prager
2016-03-22 21:05             ` Jaegeuk Kim
     [not found]           ` <56F29214.9040001@davizone.at>
2016-03-23 16:41             ` Matthias Prager
2016-03-23 21:00               ` Marc Lehmann
2016-03-24  1:29                 ` Jaegeuk Kim
2016-03-22 21:05         ` Jaegeuk Kim
2016-03-22  8:15       ` Chao Yu

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='00d401d18320$75f94e80$61ebeb80$@samsung.com' \
    --to=chao2.yu@samsung.com \
    --cc=david.gnedt@davizone.at \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux@matthiasprager.de \
    /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.