ラベル XFS の投稿を表示しています。 すべての投稿を表示
ラベル XFS の投稿を表示しています。 すべての投稿を表示

2015年4月23日木曜日

ファイルシステムの痕跡(メタデータ)をクリアする方法あれこれ(wipefsほか)

Linux で、いろいろとファイルシステムを試す際に、mkfs しようとすると、次のように残存データがあるぞと警告される場合があります。
[root@hoge ~]# cat /etc/centos-release
CentOS Linux release 7.1.1503 (Core)
[root@hoge ~]# uname -a
Linux hoge 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[root@hoge ~]# mkfs.btrfs /dev/sda10
/dev/sda10 appears to contain an existing filesystem (ext4).
Error: Use the -f option to force overwrite.
この例であれば、-f オプションを使えば良いのですが、残存するファイルシステムのシグネーチャを削除するのに wipefs コマンドを利用できます。
[root@hoge ~]# wipefs /dev/sda10    ※オプションを指定しなければ何が入ってるか確認できます
offset               type
----------------------------------------------------------------
0x438                ext4   [filesystem]
                     UUID:  xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

[root@hoge ~]# grep 0x438 /usr/share/file/magic 
0x438   leshort         0xEF53          Linux
[root@hoge ~]# hexdump -C -s 0x420 -n 48 /dev/sda10
00000420  00 20 00 00 00 20 00 00  00 08 00 00 00 00 00 00  |. ... ..........|
00000430  af 15 38 55 00 00 ff ff  53 ef 01 00 01 00 00 00  |..8U....S.......|
00000440  af 15 38 55 00 00 00 00  00 00 00 00 01 00 00 00  |..8U............|
00000450
[root@hoge ~]# wipefs -a /dev/sda10    ※-a オプションでクリアが実行されます
/dev/sda10: 2 bytes were erased at offset 0x00000438 (ext4): 53 ef

[root@hoge ~]# hexdump -C -s 0x420 -n 48 /dev/sda10
00000420  00 20 00 00 00 20 00 00  00 08 00 00 00 00 00 00  |. ... ..........|
00000430  af 15 38 55 00 00 ff ff  00 00 01 00 01 00 00 00  |..8U............|
00000440  af 15 38 55 00 00 00 00  00 00 00 00 01 00 00 00  |..8U............|
00000450
以下、その他の方法です。

昔から、中身をクリアするなら、次のように dd を使うのが常套ですが、サイズが大きいと時間かかります。
[root@hoge ~]# dd if=/dev/zero of=/dev/sda10 bs=1M
ファイルシステムのシグネーチャは、冒頭にあることが多いので、先頭だけクリアするという方法もあります。
[root@hoge ~]# dd if=/dev/zero of=/dev/sda10 bs=1M count=1
ランダムデータで埋める場合に、/dev/urandom を使うことがありますが、これは遅いので注意したほうがいいです。
[root@hoge ~]# dd if=/dev/urandom of=/dev/sda10 bs=1M

shred コマンドも利用できます。ゼロクリアする場合は、こうです。
[root@hoge ~]# shred -n 0 -z /dev/sda10
shred でランダムデータで埋めるには、こうです。dd で /dev/urandom 使うよりも、全然高速です。
[root@hoge ~]# shred -n 1 /dev/sda10
scrub という shred に似たものもあります。この手のツールは、いろいろありそうに思う。

もしも、TRIM 対応の SSD なら、blkdiscard を使えます。
[root@hoge ~]# blkdiscard /dev/sda10
これは大変便利です。HDD でも使えたらいいのになと思いますが、費用対効果上、HDD に TRIM が実装されるなどということは無いのでしょうね。
2015-09-10追記、少々古い Intel 520 で blkdiscard を使ってみたら消えないようでした(less -f で見たらゴミが見えた)。ところが、もう1回 blkdiscard したらオールゼロになったっぽい(less の出力冒頭しか確認してないので「ぽい」)。後日、検証してみます。520 は「Deterministic read ZEROs after TRIM」機能(hdparm -I の後半で確認できる)が搭載されていないからだろうとは思いましたが。。。

最後になりますが、くれぐれも対象デバイスを取り違えないように、注意しましょう。

2014年11月19日水曜日

CentOS 5 + UEKr2 で XFS を利用

CentOS 5 にオラクルの UEKr2 カーネルを入れて利用しているマシンで、実験・学習目的に XFS も動かしているのですが、この環境で xfs_db が segfault していて、気持ち悪いと思っていたのですが、よくよく考えてみると、カーネルが 3.0 系(見た目のバージョンは 2.6.39)なのに対して、xfsprogs のバージョンが古い(xfsprogs-2.9.4-1.el5.centos を使ってた)ため、何か不整合が起きているのではないかと考えました。
[root@hoge ~]# dmesg | grep xfs
xfs_db[24513]: segfault at 40 ip 0000003525408dd0 sp 00007fff34d904b8 error 4 in libpthread-2.5.so[3525400000+16000]
xfs_db[28592]: segfault at 40 ip 0000003525408dd0 sp 00007fff73492348 error 4 in libpthread-2.5.so[3525400000+16000]
xfs_db[24414]: segfault at 40 ip 0000003525408dd0 sp 00007fffdcd64d58 error 4 in libpthread-2.5.so[3525400000+16000]
xfs_db[28242]: segfault at 40 ip 0000003525408dd0 sp 00007fff890c31d8 error 4 in libpthread-2.5.so[3525400000+16000]
まず、xfs_db なんぞ自分で明示的に動かした記憶がなく、調べたところ system-config-lvm を動かすと、裏で実行されるらしく、再現性を確認しました。
そして、コミュニティ最新版 xfsprogs 3.2.1 に置き換えたところ、segfault が出なくなったことを確認しました。

以下、備忘録、xfsprogs 3.2.1 のビルド手順です。どなたかのご参考まで。

1. xfsprogs-2.9.4-1.el5.centos.src.rpm をダウンロードして展開。この中の SPEC ファイルを利用する。
# rpm -ivh xfsprogs-2.9.4-1.el5.centos.src.rpm
...
# cd /usr/src/redhat/SPEC
# cp -p xfsprogs.spec xfsprogs.spec.org
2. xfsprogs-3.2.1.tar.gz をダウンロードして、/usr/src/redhat/SOURCES へコピー
# cp xfsprogs-3.2.1.tar.gz /usr/src/redhat/SOURCES
3. xfsprogs.spec を手直しする。これが少々時間を要しました。差分です。
--- xfsprogs.spec.org   2007-10-20 23:17:33.000000000 +0900
+++ xfsprogs.spec       2014-11-18 07:43:06.000000000 +0900
@@ -1,11 +1,11 @@
 Summary: Utilities for managing the XFS filesystem
 Name: xfsprogs
-Version: 2.9.4
-Release: 1%{?dist}
+Version: 3.2.1
+Release: 1.el5.staka
 License: GPL
 Group: System Environment/Base
 URL: http://oss.sgi.com/projects/xfs/
-Source0: ftp://oss.sgi.com/projects/xfs/download/cmd_tars/%{name}_%{version}-1.tar.gz
+Source0: ftp://oss.sgi.com/projects/xfs/download/cmd_tars/%{name}-%{version}.tar.gz
 Source1: xfsprogs-wrapper.h
 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildRequires: autoconf, libtool, gettext
@@ -13,7 +13,7 @@
 BuildRequires: /usr/include/uuid/uuid.h
 Provides: xfs-cmds
 Obsoletes: xfs-cmds <= %{version}
-Conflicts: xfsdump < 2.0.0
+Conflicts: xfsdump < 3.0.0
 
 %description
 A set of commands to use the XFS filesystem, including mkfs.xfs.
@@ -69,10 +69,14 @@
 rm -f $RPM_BUILD_ROOT/{%{_lib}/*.{la,a,so},%{_libdir}/*.la}
 # fix up symlink to be correct
 rm -f $RPM_BUILD_ROOT/%{_libdir}/libhandle.so
+mkdir -p $RPM_BUILD_ROOT/%{_libdir}
 ln -s ../../%{_lib}/libhandle.so.1 $RPM_BUILD_ROOT/%{_libdir}/libhandle.so
 # remove non-versioned docs location
 rm -rf $RPM_BUILD_ROOT/%{_datadir}/doc/xfsprogs/
 
+mkdir -p $RPM_BUILD_ROOT/usr/sbin
+(cd $RPM_BUILD_ROOT/sbin ; mv xfs_{admin,bmap,copy,db,estimate,freeze,fsr,growfs,info,io,logprint,mdrestore,metadump,mkfile,ncheck,quota,rtcp} ../usr/sbin)
+
 # ugly hack to allow parallel install of 32-bit and 64-bit -devel packages:
 mv -f $RPM_BUILD_ROOT%{_includedir}/xfs/platform_defs.h \
       $RPM_BUILD_ROOT%{_includedir}/xfs/platform_defs-%{_arch}.h
@@ -89,11 +93,11 @@
 
 %files -f %{name}.lang
 %defattr(-,root,root)
-%doc doc/CHANGES doc/COPYING doc/CREDITS doc/PORTING README
+%doc doc/CHANGES.gz doc/COPYING doc/CREDITS README
 /sbin/fsck.xfs
 /sbin/mkfs.xfs
 /sbin/xfs_repair
-/%{_lib}/*.so.*
+%attr(0644,root,root)   /%{_lib}/*.so.*
 %{_mandir}/man8/*
 %{_mandir}/man5/*
 %{_sbindir}/*
@@ -101,12 +105,15 @@
 %files devel
 %defattr(-,root,root)
 %{_mandir}/man3/*
-%{_includedir}/disk
+#%{_includedir}/disk
 %{_includedir}/xfs
-%{_libdir}/*.a
+#%{_libdir}/*.a
 %{_libdir}/*.so
 
 %changelog
+* Sat Nov 15 2014 s-taka  3.2.1-1
+- upgraded to upstream version 3.2.1
+
 * Sat Oct 20 2007 Johnny Hughes  2.9.4-1
 - upgraded to upstream version 2.9.4-1
 
4. RPM パッケージをビルド。
# rpmbuild -ba xfsprogs.spec
...
# ls -1 /usr/src/redhat/RPMS/x86_64/xfsprogs-*
/usr/src/redhat/RPMS/x86_64/xfsprogs-3.2.1-1.el5.staka.x86_64.rpm
/usr/src/redhat/RPMS/x86_64/xfsprogs-debuginfo-3.2.1-1.el5.staka.x86_64.rpm
/usr/src/redhat/RPMS/x86_64/xfsprogs-devel-3.2.1-1.el5.staka.x86_64.rpm
# ls -1 /usr/src/redhat/SRPMS/xfsprogs-*
/usr/src/redhat/SRPMS/xfsprogs-3.2.1-1.el5.staka.src.rpm
5. 出来上がった RPM パッケージをインストール。
# cd /usr/src/redhat/RPMS/x86_64
# rpm -Uvh xfsprogs-3.2.1-1.el5.staka.x86_64.rpm xfsprogs-devel-3.2.1-1.el5.staka.x86_64.rpm

xfsdump については、Fedora 21 のパッケージ(xfsdump-3.1.4-2.fc21.src.rpm)を利用して、CentOS 5 向けに RPM 再ビルドしました。SPEC ファイルの差分は次の通りです。
--- xfsdump.spec.org    2014-08-19 13:24:24.000000000 +0900
+++ xfsdump.spec        2014-11-15 22:11:10.000000000 +0900
@@ -1,7 +1,7 @@
 Summary: Administrative utilities for the XFS filesystem
 Name: xfsdump
 Version: 3.1.4
-Release: 2%{?dist}
+Release: 2.el5.staka
 # Licensing based on generic "GNU GENERAL PUBLIC LICENSE"
 # in source, with no mention of version.
 License: GPL+
@@ -10,7 +10,7 @@
 Source0: ftp://oss.sgi.com/projects/xfs/cmd_tars/%{name}-%{version}.tar.gz
 BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 BuildRequires: libtool, gettext, gawk
-BuildRequires: xfsprogs-devel, libuuid-devel, libattr-devel ncurses-devel
+BuildRequires: xfsprogs-devel, libattr-devel, ncurses-devel
 Requires: xfsprogs >= 2.6.30, attr >= 2.0.0
 
 %description
@@ -65,6 +65,9 @@
 %{_sharedstatedir}/xfsdump/inventory
 
 %changelog
+* Sat Nov 15 2014 s-taka  - 3.1.4-2.el5.staka
+- Rebuilt for EL5
+
 * Mon Aug 18 2014 Fedora Release Engineering  - 3.1.4-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_21_22_Mass_Rebuild
 

■関連記事
CentOS 5 + UEK で ZFS on Linux を利用
CentOS 5 + UEKr2 で Btrfs raid1

2013年6月29日土曜日

zfs-fuse を使って CentOS 5 でも透過圧縮を利用

CentOS 5 で運用しているサーバで、容量を稼ぐのに透過圧縮可能なファイルシステムを使いたいのですが、ZFS on Linux は非対応(カーネルが古くコンパイル不可)なので、zfs-fuse を利用しようかと思います。しかし、CentOS 5 の fuse は、NFS export に対応していません。
そこで、一工夫して、透過圧縮指定した ZFS 領域にスパースファイルを作って XFS 化して、loop マウントすることで、NFS export することにしました。
※まず圧縮指定
# zfs set compression=gzip-1 tank5/test
# zfs get compression tank5/test
NAME        PROPERTY     VALUE     SOURCE
tank5/test  compression  gzip-1    local

※スパースファイル作成。CentOS 5 では truncate が用意されてないので dd 利用
# dd if=/dev/zero of=/tank5/test/sparsefile bs=1M seek=4096 count=0
0+0 records in
0+0 records out
0 bytes (0 B) copied, 2.2e-05 seconds, 0.0 kB/s

# ls -lsh /tank5/test/sparsefile 
512 -rw-r--r-- 1 root root 4.0G Jun 29 10:21 /tank5/test/sparsefile

※ext4 でもいいけれど、XFS を試したいという気持ちもありまして
# mkfs -t xfs /tank5/test/sparsefile 
meta-data=/tank5/test/sparsefile isize=256    agcount=8, agsize=131072 blks
         =                       sectsz=512   attr=0
data     =                       bsize=4096   blocks=1048576, imaxpct=25
         =                       sunit=0      swidth=0 blks, unwritten=1
naming   =version 2              bsize=4096  
log      =internal log           bsize=4096   blocks=2560, version=1
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=4096   blocks=0, rtextents=0

# mount -t xfs -o loop /tank5/test/sparsefile /mnt_temp
# df
...
/tank5/test/sparsefile
                       4184064      4384   4179680   1% /mnt_temp

※テスト書き込み
# dd if=/dev/sda of=/mnt_temp/test.dd bs=1M count=500 conv=fsync
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 16.7982 seconds, 31.2 MB/s
# ls -lsh /tank5/test/sparsefile 
211M -rw-r--r-- 1 root root 4.0G Jun 29 10:24 /tank5/test/sparsefile
この実験では、500M が 211M に圧縮されました。書き込み速度は、zfs-fuse の遅さに引きずられますが、NFS (NW が 100Mbps の環境) 経由で利用する予定なので、十分そうです。
なお、NFS のセッティング方法等は、普通にやればいいので割愛します。

2013-06-30追記
XFS のサイズ拡張(xfs_growfs)を試してみました。マウントしたまま可能でした。
スパースファイルの拡張、loop デバイスのサイズ拡張、xfs_growfs の順に行います。
※losetup -c も初めてなので、予め loop デバイスのサイズを確認
# grep loop0 /proc/partitions 
   7        0    4194304 loop0

※スパースファイルの拡張、サイズ指定を誤っても変なところに書き込まないように if=/dev/null でね
# dd if=/dev/null of=/tank5/test/sparsefile bs=1M seek=8192 count=0
0+0 records in
0+0 records out
0 bytes (0 B) copied, 1.646e-05 s, 0.0 kB/s
# ls -lsh /tank5/test/sparsefile 
236M -rw-r--r-- 1 root root 8.0G Jun 30 06:06 /tank5/test/sparsefile

※loop デバイスのサイズ認識は自動ではないので、変化なし
# grep loop0 /proc/partitions 
   7        0    4194304 loop0
# df /mnt_temp
Filesystem           1K-blocks      Used Available Use% Mounted on
/tank5/test/sparsefile
                       4184064    545056   3639008  14% /mnt_temp

※loop デバイスのサイズ再認識を実行
# losetup -c /dev/loop0 
# grep loop0 /proc/partitions 
   7        0    8388608 loop0
# df /mnt_temp
Filesystem           1K-blocks      Used Available Use% Mounted on
/tank5/test/sparsefile
                       4184064    545056   3639008  14% /mnt_temp

※XFS のサイズ拡張を実行
# xfs_growfs /mnt_temp
meta-data=/dev/loop0             isize=256    agcount=8, agsize=131072 blks
         =                       sectsz=512   attr=0, projid32bit=0
data     =                       bsize=4096   blocks=1048576, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=2560, version=1
         =                       sectsz=512   sunit=0 blks, lazy-count=0
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 1048576 to 2097152
# df /mnt_temp
Filesystem           1K-blocks      Used Available Use% Mounted on
/tank5/test/sparsefile
                       8378368    545312   7833056   7% /mnt_temp
実験の範囲では大丈夫そうです。

2013-07-03追記
サイズ拡張の検証を、間違って CentOS 6 でやってしまっていました。通常、CentOS 6 を使うことが多いもので・・・
で、残念ながら、CentOS 5 では losetup -c オプションは使えず、いちおう 2.6.18-348.el5 のソースも見てみましたが、サイズ拡張を行うためのインターフェースが未実装でした。したがって、マウントしたまま拡張は不可でした。もちろん、いったんアンマウントしてから、スパースファイル拡張して、再度マウントすればいけます。

2013-08-09追記
この形態で実際使い始めたのですが、ファイル削除の際に一工夫すると、より効果的に運用できます。具体的には次のように、削除対象ファイルをゼロ埋め後に削除するようにします。
# find remove-target-dir -type f -exec shred -n 0 -z -u {} \;
これで不要となったブロックについて、XFS から ZFS へゼロ書き込みが行われ、ZFS 側の圧縮機能により元データが使用していたブロックの大半が回収されることになります。したがって、シン・プロビジョニング(Thin Provisioning)が、より効果的に行えることになります。
なお、上記の find 後には、抜けがら(通常ファイル以外のディレクトリその他のことを言ってます:-)が残りますので、最後に rm -rf remove-target-dir もお忘れなく。

2013-10-22追記
オラクル社提供の UEK を使うことで、CentOS 5 でも ZFS on Linux や btrfs が利用できました。
こちらの記事を参照。
人気ブログランキングへ にほんブログ村 IT技術ブログへ