March 31Mar 31 Community Expert I have an odd question, related to migrating data between two XFS disks. Both were/are on V5.Background. I have been converting my XFS disks from unencrypted to xfs-encrypted.Here's where it gets weird all my disks are either Seagate IronWolf 12TB (non-pro) or WD Red Plus 12TB drives. I threw in an empty disk, formatted it as xfs-encrypted and ran rsync -aHAXx --numeric-ids /mnt/diskX /mnt/diskY then rinse and repeat up the drive order, fomat the now emtpy disk as xfs-encrupted, and re-run the rsync command for the next two disks Disk4 -> DIsk5, Disk3 -> Disk4, etc..However when I got to disk2 which was 96% full, after the rsync to disk3, disk3 is now reporting 97% full with fewer remining free space than what disk2 previous was showing. Both disks contained identical copies as I didnt delete the source data.Disk2 was showing 411GB Free where as DIsk3 was now showing 257GB free. Does this make sense? Does LUKS add several GBs of extra overhead on top of the overhead XFS already adds? I knew in my case XFS adds about 230GB of used space for the filesystem metadata/reflinks etc... but how do I "lose" an extra 150GB on top of that?Here is the image when it was nearly finished and I was already showing less free space than disk2 (you can see it is transferring 11,511,081,008,711 bytes)Im currently in the process of moving disk1 now to disk2, here is the beforeYou can see disk2 has nothing on it before I started so I know 230GB is how much the FS takes up.The question I have is does the 512 sector vs 4096 sector change how data is stored and reported?~# xfs_info md2p1 meta-data=/dev/mapper/md2p1 isize=512 agcount=11, agsize=268435455 blks = sectsz=4096 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=1 = reflink=1 bigtime=1 inobtcount=1 nrext64=1 = exchange=1 metadir=0 data = bsize=4096 blocks=2929717235, imaxpct=5 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=1 log =internal log bsize=4096 blocks=521728, version=2 = sectsz=4096 sunit=1 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 = rgcount=0 rgsize=0 extents = zoned=0 start=0 reserved=0 ~# xfs_info /dev/md1p1 meta-data=/dev/md1p1 isize=512 agcount=11, agsize=268435455 blks = sectsz=512 attr=2, projid32bit=1 = crc=1 finobt=1, sparse=1, rmapbt=0 = reflink=1 bigtime=1 inobtcount=1 nrext64=0 = exchange=0 metadir=0 data = bsize=4096 blocks=2929721331, imaxpct=5 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0, ftype=1, parent=0 log =internal log bsize=4096 blocks=521728, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 = rgcount=0 rgsize=0 extents = zoned=0 start=0 reserved=0 Edited March 31Mar 31 by MowMdown
March 31Mar 31 Community Expert Solution More recent disks formatted with XFS use more overhead, even if it was already v5, it's normal.
April 1Apr 1 Author Community Expert 21 hours ago, JorgeB said:More recent disks formatted with XFS use more overhead, even if it was already v5, it's normal.Ok so Disk1 just finished, after emptying it and before I ran a format it was showing a FS overhead of 136GB which seems quite low for a 12TB disk. After doing a format, it's now reporting 230GB FS overhead. That only accounts for about 94GB of the ~156GB difference.After Rsync was finishedAfter Disk1 was emptiedDisk1 formatted Edited April 1Apr 1 by MowMdown
April 1Apr 1 Community Expert The data itself can use a little more than before, due to the changes, as long as all the data is copied, I wouldn't worry about it.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.