マウントされたドライブRedhat 7から空き領域を取得する方法

VMインフラストラクチャには、クラスター化されたホストがSANに接続されています。

私が理解しようとしているのは、Redhatサーバー内のファイルを削除するときに、「空白」がどれだけ残っているかです。Windowsサーバーではsdeleteを使用しているため、この問題は解決されますが、Linuxでは解決策を見つけるのに苦労しています。

「空白」をセクターとして定義していますか？SSDドライブは、書き込みを行う前に最初にゼロを設定する必要があるため、ゼロのままではありません。

私が指摘することの1つは、Linuxに関して言えば、危険であると十分に知っているが、スーパーユーザーではないということです。

ドライブとパーティションを確認します。

[root@rhserver1-DATA10 /]# fdisk -l

Disk /dev/sda: 53.7 GB, 53687091200 bytes, 104857600 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x0005d52e

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048     1026047      512000   83  Linux
/dev/sda2         1026048   104857599    51915776   8e  Linux LVM

Disk /dev/sdb: 53.7 GB, 53687091200 bytes, 104857600 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/rhel_rhserver1--data10-root: 51.0 GB, 50964987904 bytes, 99540992 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk /dev/mapper/rhel_rhserver1--data10-swap: 2147 MB, 2147483648 bytes, 4194304 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

次に、ディスク使用量を確認します。

[root@rhserver1-DATA10 /]# df -h
Filesystem                              Size  Used Avail Use% Mounted on
/dev/mapper/rhel_rhserver1--data10-root   48G  6.1G   42G  13% /
devtmpfs                                906M     0  906M   0% /dev
tmpfs                                   921M  340K  920M   1% /dev/shm
tmpfs                                   921M   90M  831M  10% /run
tmpfs                                   921M     0  921M   0% /sys/fs/cgroup
/dev/sdb                                 50G  3.5G   44G   8% /ACMS01Backup
/dev/sda1                               497M  210M  288M  43% /boot
tmpfs                                   185M   20K  185M   1% /run/user/1000
tmpfs                                   185M     0  185M   0% /run/user/1002

何時間もグーグルで探した結果、これを見つけましたが、どれだけの「空白」を空けることができるかを示していると思います。

[root@rhserver1-DATA10 /]#  parted /dev/sda unit MB print free | grep 'Free Space' | tail -n1 | awk '{print $3}'
1.02MB
[root@rhserver1-DATA10 /]#  parted /dev/sda unit '%' print free | grep 'Free Space' | tail -n1 | awk '{print $3}'
0.00%

497Mパーティションの合理的な出力だと思います。

だから今、私は自分のマウントされたドライブでのみ同じことをしたいです（マウントされていると思います）

 parted /dev/mapper/rhel_rhserver1--data10-root unit MB print free | grep 'Free Space' | tail -n1 | awk '{print $3}'
 parted /dev/mapper/rhel_rhserver1--data10-root unit '%' print free | grep 'Free Space' | tail -n1 | awk '{print $3}'

それは私に何も与えません。

私の/ etc / fstab /：

[root@rhserver1-DATA10 /]# cat /etc/fstab
/dev/mapper/rhel_rhserver1--data10-root /                       xfs     defaults        0 0
UUID=2f97a17c-a6d5-4904-ad5c-7c16b4510201 /boot                   xfs     defaults        0 0
/dev/mapper/rhel_rhserver1--data10-swap swap                    swap    defaults        0 0
/dev/disk/by-uuid/be4c45cf-5d72-4b97-b647-2e585947041f /ACMS01Backup auto nosuid,nodev,nofail,x-gvfs-show 0 0

だから私の質問は、私は正しい道を進んでいますか？

私が探しているものを説明しましたか？

グーグル検索に役立つ「ホワイトスペース」という用語はありますか？

ルートで「fstrim -v /」を実行できることがわかりましたが、実際にどのくらいのスペースがあるかを知りたいと思います。

また、私はこれらが実稼働システムであることがfstrim I / O集中型であることを把握しようとしていますが、ピーク時間外に実行する必要がありますか？

「fstrim -v /」を実行してデータ損失の可能性はありますか？

/パーティションでfstrimを実行できることが最善の解決策ですが、ESXiを構成する方法では不可能です。

VMとストレージデバイスの両方で破棄を有効にする必要があります。

xfsファイルシステムを使用してパーティションまたは論理ボリュームのサイズを縮小しようとすることはできません。これはfedoraの既知のバグです。この機能に興味がある場合は、Red Hatサポートに連絡してRed Hat bugzilla 1062667を参照し、XFSの縮小/縮小が必要なユースケースを提供してください。

一部の環境で可能な回避策として、シンプロビジョニングされたLVMボリュームをXFSファイルシステムの下の追加レイヤーと見なすことができます。

VMが熱心なシックプロビジョニングされたVMDKである場合、つまり、ボリュームをトリム（技術的にはSCSI UNMAP）しようとしたときに再利用するものが何もないことを意味します。

バックエンドストレージがシンプロビジョニングを実行している場合、ストレージを削減し、バックエンドがウォームデータをキャッシュ/重複削除できるようにするために、遅延ゼロVMDKファイルも使用する必要があります。

2つの可能なオプション：

1. SAN上のリモートサーバーによってストレージが提供される場合、ストレージがシンプロビジョニングされている場合にのみブロックを破棄できます。

   1. すべてのVMを別のデータストアにVMotionし、組み込みのVMWareツールを使用する
   2. SSHを使用してESXiホストに接続する
   3. 仮想マシンフォルダーに移動します
   4. duを使用してディスク使用量を確認する
   5. vmkfstools -K [ディスク]を実行します
   6. duを使用してディスク使用量を確認する

2. dd if = / dev / zero of = BIGFILE bs = 1024000 rm -f BIGFILE

私が言うことができることから、これはsdeleteと同じことをしますが、ディスクI / Oのスパイクを引き起こし、実行に時間がかかる可能性があります。

一晩試すもの

どちらのオプションも最適ではありませんが、ext3またはext4を取得するためにすべてのVMを再フォーマットすることは現実的ではありません。

できるのは、すべてのLinux VMにアフィニティルールを設定し、上記のオプション1を使用することです。

数週間前に同じことをしようとしていますが、方法がわかりません。Redhatサポートポータルで公式声明を共有しています。

現在、xfsファイルシステムを使用してパーティションまたは論理ボリュームのサイズを縮小することはできません。この機能に興味がある場合は、Red Hatサポートに連絡してRed Hat bugzilla 1062667を参照し、XFSの縮小/縮小が必要なユースケースを提供してください。一部の環境で考えられる回避策として、シンプロビジョニングされたLVMボリュームをXFSファイルシステムの下の追加レイヤーと見なすことができます。

幸運を！！