From: joerg jungermann <jj@borkum.net>
To: linux-f2fs-devel@lists.sourceforge.net
Subject: possible endianes bug in mkfs.f2fs roll-forward speed
Date: Thu, 25 Sep 2014 18:05:51 +0200 [thread overview]
Message-ID: <20140925160551.GA30960@borkum.net> (raw)
Hi,
I might found a bug in mkfs.f2fs. while experimenting with f2fs on my big
endian MIPS32 device (platform lantiq, 14.07-rc3, uclibc).
I ran into an issue that mkfs.f2fs, was not able to format block devices if i did not
specify the sector count manually.
I hunted it down to lib/libf2fs.c.
After I found that the detected sector count equals to the wanted sector count shifted left (32+9) times.
I found two issues:
Firstly it uses ioctl BLKGETSIZE, which writes to an uint32_t the size of the device.
As c->total_sectors is of type uint64_t, the value is written in to the first 4 bytes.
That explained the left shift of 32 bits.
Secondly BLKGETSIZE determines the size of the device in bytes (AFAIK, learned by observation).
In the first branch of the if-block patched below, the c->total_sectors is calculated by
c->total_sectors = stat_buf.st_size / c->sector_size;
The else branch omits the devision. sector_sice is mostly 512, that explained the left shift by 9 bytes.
I prepared patch against 1.4.0, not HEAD, sorry.
* fixes sector count calculation
* uses BLKGETSIZE64 if avail
best regards
--- lib/libf2fs.c.orig 2014-09-25 17:41:56.433763287 +0200
+++ lib/libf2fs.c 2014-09-25 17:45:04.944604490 +0200
@@ -453,11 +453,21 @@
c->sectors_per_blk = PAGE_SIZE / sector_size;
}
}
-
- if (ioctl(fd, BLKGETSIZE, &c->total_sectors) < 0) {
+#ifdef BLKGETSIZE64
+ if (ioctl(fd, BLKGETSIZE64, &c->total_sectors) < 0) {
+ MSG(0, "\tError: Cannot get the device size\n");
+ return -1;
+ }
+ c->total_sectors /= c->sector_size;
+#else
+ uint32_t total_sectors;
+ if (ioctl(fd, BLKGETSIZE, &total_sectors) < 0) {
MSG(0, "\tError: Cannot get the device size\n");
return -1;
}
+ total_sectors /= c->sector_size;
+ c->total_sectors = total_sectors;
+#endif
if (ioctl(fd, HDIO_GETGEO, &geom) < 0)
c->start_sector = 0;
--
Joerg Jungermann
------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
reply other threads:[~2014-09-25 16:06 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20140925160551.GA30960@borkum.net \
--to=jj@borkum.net \
--cc=linux-f2fs-devel@lists.sourceforge.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).