linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Luciano ES <lucmove@gmail.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: Supposedly identical file system wastes space
Date: Mon, 6 Nov 2017 17:19:28 +1100	[thread overview]
Message-ID: <20171106061928.GD5858@dastard> (raw)
In-Reply-To: <20171007114343.3bd42f98@lubh.lubhome>

On Mon, Nov 06, 2017 at 01:15:50AM -0200, Luciano ES wrote:
> I have two 1TB disks, one of them on USB. The USB disk is supposed 
> to be a backup copy of the internal disk.
> 
> I run this command:
> 
> rsync -aSHxv --delete-before /xx/ /media/usbxx/
> 
> After all the copying, I get this output from df -h:
> 
> Filesystem         Size  Used Avail Use% Mounted on
> /dev/mapper/cxx    931G  520G  411G  56% /xx
> /dev/mapper/usbxx  932G  529G  403G  57% /media/usbxx
> 
> So the USB disk takes up 9GB more than the internal disk.
> 
> Why?
> 
> That is not a problem now, but will be when the disks are nearly full.
> 
> I investigate:
> 
> ---------------- 8< ----------------
> #> xfs_info /xx
> meta-data=/dev/mapper/cxx    isize=256    agcount=8, agsize=30506944 blks
>          =                   sectsz=4096  attr=2, projid32bit=1
>          =                   crc=0        finobt=0 spinodes=0 rmapbt=0
>          =                   reflink=0
> data     =                   bsize=4096   blocks=244055552, imaxpct=25
>          =                   sunit=0      swidth=0 blks
> naming   =version 2          bsize=4096   ascii-ci=0 ftype=0
> log      =internal           bsize=4096   blocks=119167, version=2
>          =                   sectsz=4096  sunit=1 blks, lazy-count=1
> realtime =none               extsz=4096   blocks=0, rtextents=0
> 
> #> xfs_info /media/usbxx
> meta-data=/dev/mapper/usbxx  isize=512    agcount=8, agsize=30523735 blks
>          =                   sectsz=512   attr=2, projid32bit=1
>          =                   crc=1        finobt=1 spinodes=0 rmapbt=0
>          =                   reflink=0
> data     =                   bsize=4096   blocks=244189877, imaxpct=25
>          =                   sunit=0      swidth=0 blks
> naming   =version 2          bsize=4096   ascii-ci=0 ftype=1
> log      =internal           bsize=4096   blocks=119233, version=2
>          =                   sectsz=512   sunit=0 blks, lazy-count=1
> realtime =none               extsz=4096   blocks=0, rtextents=0
> ---------------- >8 ----------------
> 
> Looks like the only difference between them is the isize. But both were 
> formatted with the exact same line:
> 
> mkfs.xfs -f -b size=2048 -d agcount=8 /dev/target

With different versions of mkfs. One is a old v4 format filesystem,
the other is a v5 format filesystem which uses metadata CRCs, uses
larger inodes, has a free inode btree, has ftype enabled on
directories, etc....

> For the first time, I tried to introduce the -i size=256 option, 
> but mkfs.xfs is not having it:
> 
> "Minimum inode size for CRCs is 512 bytes"
> 
> Why not? They are the same size! Why do they have different inode sizes?

Because the v5 format is enabled by default now and that requires
512 byte inodes.

> Why is the external disk "wasting" space and how do I avoid that?

Its not wasting space. If you want it to be identical to your old
disk, then use "mkfs.xfs -m crc=0 ....", but I really don't advise
that because you are using USB drives for your backups and they need
all the silent corruption detection help they can get....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

      parent reply	other threads:[~2017-11-06  6:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-07 14:43 Questions about backups with XFS Luciano ES
2017-10-09  8:44 ` Carlos Maiolino
2017-10-09 10:57   ` Dave Chinner
2017-10-12  1:03     ` Luciano ES
2017-10-09 15:08   ` Carlos E. R.
2017-10-12  0:58   ` Luciano ES
2017-10-12  5:13     ` Keith Keller
2017-11-06  3:29 ` Supposedly identical file system wastes space Carlos E. R.
2017-11-06  6:19 ` Dave Chinner [this message]

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=20171106061928.GD5858@dastard \
    --to=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=lucmove@gmail.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 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).