タグ付けされた質問 「xfs」

XFSは、もともとSGIのIRIX OS用のファイルシステムですが、現在Linuxでも利用できます。16.8TBを超えるパーティションを処理できる数少ないLinuxファイルシステムの1つである、大きなファイルと大きなファイルシステムを適切に処理することで知られています。


2
isyncテーブルが時間とともに急激に縮小し、rsync / inodeの問題が発生する
Linux(それはAmazon AWS、CentOSのようなシステム上にありますが、カスタマイズは正確には行われていません)を、LVM上のXFSボリュームとして4TBストレージでセットアップします(最終的にはNFS4経由での提供に使用されますが、まだ使用されていません)、rsyncを使用してファイルを本番のNFSサーバーからXFSボリュームに同期しています(つまり、NFS経由のソースからローカルにマウントされたXFSベースのLVMボリュームにrsyncを実行しています)。ただし、中間のある時点でrsyncがますます遅くなり始め(スループットが大幅に低下)、負荷平均とメモリ消費の両方が大幅に増加しました(そしてCPUはiowaitで非常に大きな割合を占めています)。最終的に私はXFSシステムをリブートし、システムは通常の状態に復帰したようです。少なくとも24時間はrsyncのパフォーマンスがより正常でした。 muninのモニタリンググラフを確認したところ、明らかなことは何もわかりませんでしたが、「Inode table size」および「open inode」メトリック(/ proc / sys /から読み取られる値を指すmuninプラグインの実装を確認しました) fs / inode-nr)は時間とともに減少し続けました。rsyncがスタックするのを観察する少し前に、両方のメトリックが数十万から数千の値に下がっているのを観察しました(非XFSサーバーはほとんどの場合ほぼ500,000のままで、長期間にわたって単調な減少傾向を示しません) )、次のようなカーネルからのログを観察しました: ip-XX-XXX-XXX-XXXログイン:[395850.680006] hrtimer:割り込みは20000573 nsかかりました Sep 18 17:19:58 ip-XX-XXX-XXX-XXXカーネル:[395850.680006] hrtimer:割り込みは20000573 nsかかりました [400921.660046]情報:タスクrsync:7919が120秒以上ブロックされました。 [400921.660066]「echo 0> / proc / sys / kernel / hung_task_timeout_secs」はこのメッセージを無効にします。 [400921.660077] rsync D ffff880002fe4240 0 7919 7918 0x00000000 [400921.660093] ffff8800683e5638 0000000000000282 ffff880000000000 0000000000014240 [400921.660131] ffff8800683e5fd8 0000000000014240 …
12 linux  rsync  xfs 

2
SLES 10サーバーへの60TBストレージの追加
SLES 10サーバーにいくつかのアーカイブ/ステージングストレージを追加する必要があります。要件は、大きな画像ファイル(大部分が150MegのTiff)からなるアーカイブデータ(文字通り、これはライブラリ用)を格納するために使用されるかなり大きなボリューム(それぞれ約9-20TB、合計で60TB程度)を提示することです。大きなtarball。データはIOを読み取るように圧倒的にバイアスされ、確かに95%を超え、おそらく99%を超えるでしょう。 ストレージはすでに購入済みです-2 TB 7200 RPM SATAドライブを完全に搭載した2台のMD1000とデイジーチェーン接続されたDell MD3000 SASアレイ、合計45台のドライブ。アレイのスタックは、2つのデュアルポート外部SASアダプターを使用して接続されます。つまり、スタックには4つのパスがあります。 私の意図は、これらを、アレイごとに1つのホットスペアを持つ4つのRAIDグループ上にある4つのボリュームのセットとして構成することです。すべてのグループは7または14ドライブのRAID 6であり、各RAIDグループはそのグループのすべての容量を使用する単一のLUNとして提示されます。SLES側では、これらをXFSボリュームとしてフォーマットする必要があります。 私はSLES(およびLinux全般)の経験が限られているため、これに関するいくつかの推奨事項を具体的に探しています。 SLES 10でこのサイズのXFSボリュームを構成する際に注意すべき特定の事項はありますか?つまり、IOプロファイルが与えられれば、デフォルト設定で問題ありませんか? これらを初期化\パーティション\フォーマットする最良の方法は何ですか?Partedを使用してディスクラベルを設定し、YASTパーティションマネージャー(すべてのデフォルトを受け入れる)を使用して、最初のテスト用のXFSボリュームを作成およびフォーマットしました。 マルチパスを設定するにはどうすればよいですか?最初のテストボリュームを提示すると、4つの別個のデバイス(/ dev / sdl、/ dev / sdm、/ dev / sdnおよび/ dev / sdn)として表示されます。これを1つのボリュームとして扱うにはどうすればよいですか? 最初のテストで、既存のEMC Clariion SANボリュームからの転送速度が約30Meg /秒であることがわかりました。これは予想よりもはるかに低く、RAID 6の書き込みペナルティを考慮しても、70-100Meg /秒のボールパークで何かが見られると予想していました。 すべてが大丈夫かどうかはどうすればわかりますか-エラー/警告などをどこで探すべきですか?たとえば、YASTパーティションエディターの起動には非常に長い時間がかかります。その理由を知りたいのですが。 これを別の方法でパーティション化し、別のファイルシステムを使用しますか? サーバーはDell 2950です-詳細な仕様を確認していませんが、一番上は使用率が1桁以下でホバリングしていることを示しています。

2
CentOS 6はCentOS 5よりも多くのIOを実行
私は2つの同じサーバーでアプリケーションをベンチマークしています。1つはCentos 5.8で、もう1つはCentos 6.2です。私のアプリケーションは、Centos 6.2マシンで非常に遅く(50%以下)実行されています。 問題を診断するために、ベンチマークの実行全体を通じてCPU、RAM、およびIOを追跡しています。Centos 6.2ボックスでは、iostatで測定すると、ディスクの読み取りが大幅に多いことがわかります。 どちらのシステムも、ベンチマークが実行されている場所でXFSを実行しています。どちらも、512 MBキャッシングRAIDコントローラーを搭載したHPサーバーで、RAID 10を実行する8 x 300GB SAS 以下は、それぞれのxfs_infoの出力です。 centos5 meta-data=/dev/cciss/c0d0p5 isize=256 agcount=32, agsize=8034208 blks = sectsz=512 attr=0 data = bsize=4096 blocks=257094144, imaxpct=25 = sunit=32 swidth=128 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=32768, version=1 = sectsz=512 sunit=0 blks, lazy-count=0 realtime =none extsz=4096 blocks=0, …

2
ハードウェアRAID上のlvm上のxfs:正しいパラメーター?
ハードウェアRAID6にそれぞれ8 TBのディスクが10個あります(したがって、8個のデータディスク+ 2個のパリティ)。非常によく似た質問の答えに続いて、すべての必要なパラメータの自動検出を望みました。しかし、最後にXFSファイルシステムを作成すると、 # mkfs.xfs /dev/vgdata/lvscratch meta-data=/dev/vgdata/lvscratch isize=256 agcount=40, agsize=268435455 blks = sectsz=4096 attr=2, projid32bit=1 = crc=0 finobt=0 data = bsize=4096 blocks=10737418200, imaxpct=5 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 ftype=0 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 これは、そのストライプが使用されていないようです。サイトごとに異なる用語(ストリップサイズ、ストライプサイズ、ストライプチャンクなど)が見つかったため、手動パラメーターが正しいかどうかを確認したいと思います。 …
10 raid  lvm  xfs 

1
64KBブロックサイズでXFSからファイルを取得する
私は、RAID 1にあった、完全に機能し、破損しておらず、暗号化されていない2つのNASドライブの1つからファイルを回復する使命を帯びていました。NASはPatriot Javelin S4でした(私の調査でわかったように)Promise FasttrackフェイクRAIDコントローラを使用します。 これに関する情報は非常に少ないため、同じ状況のグーグルにとって、このNASに関するいくつかの事実があります。 RAIDコントローラー:Promise FastTrack(FakeRaid) ボリュームシステム:LVM2 ファイルシステム:64kbブロックサイズ(65536バイト)のXFS Arch:800MHz AMCC PowerPCプロセッサ、256MB RAM(Matthewの研究に感謝) これを行ったとき、私はWindows 10とMacOSコンピュータしか持っていませんでした。LVM2ボリュームにXFSをマウントできるソフトウェアは見つかりませんでした(1つを例外として、以下で詳しく説明します)。私は古いネットブックAcer Aspire Oneを取り出し、それにpuppy linux(具体的にはlxpupフレーバー)をインストールする必要がありました。 子犬のLinuxでは、と呼ばれるツールを使用してこのファイルシステムをマウントできましたdmraid。このツールには、Promise FastTrackのIDであるpdcボリュームをマウントする方法があります。なんとかそれをマウントしているいくつかのフープを飛び越えることができたら、私は実際のXFSファイルシステムにアクセスできるようになり、そして残念なことに、それは64kbのブロックサイズであることがわかりました。 ここで、「read xfs 64kb block size」のようなものをググって始めて、どこにも行きませんでした。「カーネルにパッチを適用しない限り、Linuxは4kbを超えるブロックサイズを読み取ることができません」と答えるのはほんのわずかです。カーネルにパッチを当てる方法がわかりませんし、これを可能にするエミュレーションもないので困惑しています。 Win / Macでこのパーティションを読み取ることができないアプリの1つの例外について言及しました。その例外はufsexplorerでした。100ドルのアプリで、シ​​ームレスにファイルを表示できました。私はそれが機能することを証明するいくつかのファイルをコピーしましたが、試用版では小さなファイルしかコピーできません。 64kbのxfsを読み取るのに役立つような複雑さのレベルにある無料のオープンソースツールはありません。 私の質問は、そのようなツールを誰かが知っていますか?1つ以上のツール、カーネルパッチ、または他の何か(無料)を使用してデータを取得する方法についての具体的な指示があれば、高く評価されます。 もう1つのポイント:これらのドライブのローカルイメージを作成する必要がないことを強く望みます(それが唯一の方法でない限り)。結局のところ、それは2TBのデータであり、私はこれほどのスペースを持っていないかもしれません。 PS 64 kbのxfsを読み取ることができる既知のLinuxがAcerにインストールできる場合、それも実行可能なソリューションです。 更新1:https://www.cgsecurity.org/wiki/TestDiskについて学んだところです。一撃の価値があるかもしれません。試してみる時間があったらまた報告します。 Update 2:TestDiskはXFSパーティションの存在を認識しているようですが、そこに進む方法がわかりません。ファイルを抽出する方法がわからないので、今はそれを放棄し、マシューの答えでqemuアプローチを試しました。

2
CEPHの未加工スペース使用量
ceph rawスペースの使用状況を理解できません。 7台のサーバーに14台のHDD(14個のOSD)があり、各HDDが3TBで、合計で42TBのrawスペースがあります。 ceph -s osdmap e4055: 14 osds: 14 up, 14 in pgmap v8073416: 1920 pgs, 6 pools, 16777 GB data, 4196 kobjects 33702 GB used, 5371 GB / 39074 GB avail それぞれ5 TBの4つのブロックデバイスを作成しました。 df -h /dev/rbd1 5.0T 2.7T 2.4T 54% /mnt/part1 /dev/rbd2 5.0T 2.7T 2.4T 53% /mnt/part2 /dev/rbd3 …
8 centos  xfs  ceph 

1
Amazon EC2 ext4 EBSボリュームをXFSファイルシステムに変換する
Amazon EC2 ext4ファイルシステムをXFSファイルシステムに変換して、一貫したスナップショットを取得してS3に送信できるようにする必要があります。us-eastでi686アーキテクチャを備えたubuntuサーバー10.10のカスタムの小さなイメージを使用しています。問題は、すべてのファイルに1つのEBSドライブしか使用していないことです。sshからインスタンスにログインすると、ドライブのマウントを解除したり、フォーマットしたり、何も実行したりできないため、問題が発生します。私の推測では、EBSボリュームを2つに分割し、/ var / wwwと/ var / libを2番目のEBSボリュームに移動して、代わりにXFSに変換する必要があります。私はapache2、mysql、ispconfig、bind、postfix、courier、pureftp(http://www.howtoforge.com/perfect-server-ubuntu-10.10-maverick-meerkat-ispconfig-3)を使用しています ありがとうございました。

3
データを失うことなくファイルシステムのフォーマットをxfsからext4に変更する
新しいLucid Lynx(Ubuntu 10.04)をラップトップで実行しています。ここで、ファイルシステムを次のように定義しました。 マウントポイント/ ext4(46 Gb) jfs上のマウントポイント/ home(63 GB) 3 Gbとしてスワップ AC電源なしで、私はいくつかのタスクを実行するために機械を一晩放置しました。翌日の朝、私はそれをスタンバイで見つけ、タスクは完了しましたが、ファイルシステムに到達できませんでした。I / Oエラーが発生した jfsとstandbyに問題があるようです。 とにかく、面倒を避けるために、このマウントポイントをjfs形式からext4に移動したいと思います。 データを失うことなく、変換が完了するまでデータを一時的な場所に置く必要なく、これを行うことができますか? 申し訳ありませんが、Windowsの時代には、データを失うことなくFAT16をFAT32に、またはFAT32をNTFSに変更することを思い出します。これがLinuxで利用できることを願っています。 更新 / homeファイルシステムはjfsではなくxfsであり、何らかの理由でこのファイルシステムにバグがあるようです。全体がext4になるまでOSを2回再インストールする必要がありました/ ただし、結論としては、変換する方法がないようです
8 linux  ubuntu  xfs  ext4  jfs 

4
SSDにXFSログを配置すると、パフォーマンスが大幅に向上しますか?
RAID5でXFSを実行している5つのディスクアレイがあり、そのパフォーマンスを改善したいと考えています。ログを別のデバイスに置くと効果的であるというヒントをいくつか見ましたが、ログをSSDに置くと劇的に役立ちますか? 理論的にはそうですが、実際に誰かがこれを実行したケーススタディを見つけることはできませんでした。SSDを購入した後、SSDがうまく機能しないのは、せいぜい不便なことです…
8 ssd  xfs 

3
ファイルシステムを破壊する方法
以前はメモリ使用量が多かったため、いくつかの大きなファイルシステム(約50 TB)で「xfs_repair」をテストします。正しいファイルシステムでのみプログラムをテストできましたが、破損したシステムでテストすることをお勧めします。 では、ファイルシステムを破損させる最善の方法は何でしょうか。メソッドが繰り返し同じ破損を毎回与える場合の追加のクレジット.... 2006年に私が何を意味しているのかを人々に知らせるために 「マルチテラバイトのファイルシステムで修復を正常に確認または実行するには、次のものが必要です。 64ビットマシン 64ビットxfs _ repair / xfs _チェックバイナリ ファイルシステムのテラバイトあたり最大2GBのRAM ファイルシステムの100万iノードあたり100〜200 MBのRAM。 xfs_repairは通常これよりも少ないメモリを使用しますが、これらの数値は、80%を超えるフルファイルシステムが修復に必要とする可能性があるものについて、大まかな数値を与えます。 FWIW、これが最後に内部で発生したとき、問題の29 TBのファイルシステムは、修復に最大75 GBのRAM +スワップを必要としました。」
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.