All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthias Schniedermeyer <ms@citd.de>
To: nscott@aconex.com
Cc: xfs@oss.sgi.com
Subject: Re: mkfs.xfs doesn't detect size of storage correctly
Date: Tue, 29 Jan 2008 13:20:51 +0100	[thread overview]
Message-ID: <20080129122051.GA18165@citd.de> (raw)
In-Reply-To: <43347.192.168.3.1.1201601702.squirrel@mail.aconex.com>

On 29.01.2008 21:15, nscott@aconex.com wrote:
> > Hi
> >
> >
> > Yesterday i bought a 750GB HDD.
> > I encrypt nearly everything with loop-aes, so i also did it with this
> > HDD.
> >
> > I create a "fake" partition table and:
> > losetup -e aes256 -p 0 -o 4096 /dev/loop6 /dev/sdb < key
> >
> > This creates a loop with everything except the first 4KB, i.e. it leaves
> > out the MBR and another 3,5KB.
> >
> > /proc/partions shows the correct(tm) size informations for the HDD and
> > the loop:
> > - snip -
> >    7     6  732574580 loop6
> >    8    16  732574584 sdb
> >    8    17  732572001 sdb1
> > - snip -
> >
> > But when i mkfs.xfs the loop
> > #> mkfs.xfs /dev/loop6
> > meta-data=/dev/loop6             isize=256    agcount=3, agsize=45785911
> > blks
> >          =                       sectsz=512   attr=2
> > data     =                       bsize=4096   blocks=137357733, imaxpct=25
> >          =                       sunit=0      swidth=0 blks
> > naming   =version 2              bsize=4096
> > log      =internal log           bsize=4096   blocks=32768, version=2
> >          =                       sectsz=512   sunit=0 blks, lazy-count=0
> > realtime =none                   extsz=4096   blocks=0, rtextents=0
> >
> > And mount it:
> > mount /dev/loop6 /mnt
> >
> > And least but not least df it:
> > #> df -m /mnt
> > Filesystem           1M-blocks      Used Available Use% Mounted on
> > /dev/loop6              536426         5    536422   1% /mnt
> >
> > There is roughly 1/3 missing.
> >
> > What can i do to fix this?
> 
> mkfs.xfs uses the BLKGETSIZE64 ioctl to extract the device size, so
> the problem is likely in the loop device driver (just a guess).  You
> can use the test program xfs-cmds/xfstests/src/getdevicesize.c to
> test what that device returns as its size (no XFS-specific code in the
> test program, so if it returns bad data we've narrowed down the root
> cause a whole lot).
> 
> What does that program produce for your device?

After a little odyssey to actually finding getdevicesize.c :-)

#> wget 'http://oss.sgi.com/cgi-bin/cvsweb.cgi/~checkout~/xfs-cmds/xfstests/src/getdevicesize.c?rev=1.3;content-type=text%2Fplain' -O getdevicesize.c
#> gcc -o getdevicesize getdevicesize.c
#> ./getdevicesize /dev/loop6
1465149160 512 byte blocks (BLKGETSIZE64)

Which is 750156369920 bytes or 732574580 KBytes, IOW EXACTLY the number 
reported in /proc/partions for the loop.



A maybe important detail, i forgot to mention in the original mail is:
The machine has 8GB of RAM, so i compiled the kernel with "64bit=yes" 
(formaly x86_64), BUT(!) the userspace is 32bit or plain old i386.

I only need the RAM for a large tmpfs. So i didn't reinstall the machine 
with a 64bit userspace when i switched the hardware from a Dual P3 with 
3GB to a Core2Duo with 8GB.




Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

  reply	other threads:[~2008-01-29 12:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-29  9:32 mkfs.xfs doesn't detect size of storage correctly Matthias Schniedermeyer
2008-01-29 10:15 ` nscott
2008-01-29 12:20   ` Matthias Schniedermeyer [this message]
2008-01-29 15:19     ` Eric Sandeen
2008-01-29 15:33       ` Matthias Schniedermeyer
2008-01-29 15:42         ` Eric Sandeen
2008-01-29 16:58           ` Matthias Schniedermeyer
2008-01-29 17:16 ` Matthias Schniedermeyer
2008-01-29 20:14   ` Eric Sandeen
     [not found]     ` <20080129203731.GA29094@puku.stupidest.org>
2008-01-29 21:21       ` Eric Sandeen
2008-01-30 23:26   ` Matthias Schniedermeyer
2008-01-31  3:17     ` Eric Sandeen
2008-02-05 14:53 ` Eric Sandeen
2008-02-05 15:33   ` Matthias Schniedermeyer
2008-02-05 21:12   ` Mark Goodwin

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=20080129122051.GA18165@citd.de \
    --to=ms@citd.de \
    --cc=nscott@aconex.com \
    --cc=xfs@oss.sgi.com \
    /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.