12/07/22 22:48:16.24 MQuOFVdZ
>>75
zfsのオプションです
sync=diabled：ZILデバイスには書き込まない
sync=standard：O_SYNCのときだけ(ZILデバイスに）同期書き込み
sync=always：常に(ZILデバイスに）同期書き込み
よく分かってないので間違ってるかも知れません
77:login:Penguin
12/07/23 10:28:49.30 1fiDJHgv
ZFSをCentOSのデスクトップ環境で３ヶ月使い続けた結論
ディスクの玉は多いほど読み書きが速くなる
ｰ>ボードの性能がボトルネックになる。
logsは多くても数Mしか使っていない、512MぐらいSSD割り当てれば十分。（か？）
cacheは徐々にallocが増えていくので、時間が経てば効果がでる。（かも？）
容量は多いほうが良い？ 24GをSSDに割り当てている。
ー＞目立った効果を感じられない。
圧縮、重複排除機能はOFFの方が安定しているみたい。
ー＞重複排除で20%～30%の容量節約になるのは魅力だが、書き込みが遅くなる。
メモリー8Gから16Gに増やしたので、そろそろフルで重複排除を働かそうか
と思っている。
78:login:Penguin
12/07/23 11:06:10.88 7/xA481o
>>77
FreeBSDのZFSで3TBx5発のraidz2を使ってるが、シーケンシャルでRead 500M/s
Write 420M/s行ったよ。ボードがボトルネックって、単に使ってるボードがPCIex1だった
とかのオチじゃないの?
79:login:Penguin
12/07/23 11:09:41.71 A8ZoFuFU
ZILの容量はメモリの1/2で十分らしい
URLﾘﾝｸ(www.solarisinternals.com)
The maximum size of a log device should be approximately 1/2 the size of physical memory because that is the maximum amount of potential in-play data that can be stored.
For example, if a system has 16 GB of physical memory, consider a maximum log device size of 8 GB.
80:77
12/07/23 11:49:20.51 1fiDJHgv
>>78
うん。御名答。
どんなに頑張っても100M/S以上の書き込みができないオンボードのSATA-I/Fなので
がっかりな結果。RAIDカードを買っても結果は同じだろうと思います。もともとは
ホビー用途のボードらしいです。
ただ、書き込みの時にraidz2で30M/Sずつの書き込みで60M/Sの書き込み
読み込みの時に、30M/Sずつの読み込みで90M/Sの性能が出ているのは、
ストライピングの効果が見えて面白い。サーバ向けのボードで使いたいよ。
81:login:Penguin
12/07/23 16:01:42.86 yZecj+X2
で 用途は？
ただのベンチヲタ？
82:login:Penguin
12/07/23 16:02:45.52 dc9u8nYx
>78
read はともかく write は
dd でシーケンシャルテストしても
数十MB/s とか程度だった気がするんだけど
なにが違うんだろう(FreeBSD 8系で raidz1, 1TBx4発)
お勧めパラメータ設定とかあります?
zpool iostat で見ていると安定して書き込まないで
ちょっと書いては休んでとかしてたのが謎…
83:login:Penguin
12/07/23 17:04:49.42 A7MoWAQa
>>82
休んでるっつーのは ARC に書きに行ってるときじゃね?
つーかパラメータ云々よりどんな構成で使ってるんだ
84:login:Penguin
12/07/23 18:03:36.80 EDgInYkW
LSIのSAS HBAでZFS使っている人いる？
85:login:Penguin
12/07/23 19:32:04.03 7/xA481o
>>82
数十MB/sって…。
raidz1x4の構成なら、仮にHDD 1本あたり34MB/s出ればpool単位では
100MB/s越えちゃうんだよ。むしろどうやればそんな低い性能になるのか、
そっちの方がギモンだ。
86:login:Penguin
12/07/23 19:45:48.60 Fr1Xt2TT
RAIDZってそんなに書き込み性能出るの？
普通、RAID5/6ってのは単体と比較して
書き込みの回転待ちが倍近くかかるし
chunkサイズx台数に比例したサイズの整数倍以外で書き込み以外は
パーシャルライトになって、強烈に性能が低下するものだと思ってたよ。
実体験上もそうだし。
87:login:Penguin
12/07/23 19:55:13.73 Fr1Xt2TT
で、書き込み性能低下の要因は
メディアの転送速度でも、インターフェース(のどこか)の転送速度でも
ましてやパリティの計算に使うCPUでもなく
もっと根本的な、回転待ちの同期と、一部書き換えのための事前読み込みに
時間がとられることじゃないかと。
もうひとつ遅くなる原因に思い当たった気がしたんだけど思い出せない。
88:login:Penguin
12/07/23 20:00:25.48 NpgI32SJ
俺の家でパラメータとか何にも考えずに構築した2TB*4のRAID-Zは安定して150MBぐらいは出てるな
ちなみにHP ProLiant MicroServerのFreeBSD。
89:login:Penguin
12/07/23 21:11:52.13 F+qS+uAy
ってことで URLﾘﾝｸ(ftp-admin.blogspot.jp)
90:login:Penguin
12/07/23 21:13:35.60 F+qS+uAy
ちなみにIOPSではなく転送速度ってことなら、シーケンシャルでドカンと
読み込む場合はRAID-Zでも速いです。
91:login:Penguin
12/07/24 08:20:25.96 4u7D0Pvy
うちは何も考えずに作った 2TB*8 の RAIDZ2 で 400MB くらいだな
作ったばっかの頃はもうちと出てた気がする
AthlonX4 と 16GB メモリ の FreeBSD 8.2
HBA は M1015(LSI 9220-8i) の IT Firmware
92:login:Penguin
12/07/24 09:24:18.51 Q2zpsPpk
>>91
LSI 9220-8iで故障したディスクの特定とかってどうやってます？
93:login:Penguin
12/07/24 09:55:42.87 4u7D0Pvy
>>92
いまんとこ mptutil(8) に相当するのが無い
mpsutil が出るのまち。いつになんのかしらんけど
94:login:Penguin
12/07/24 10:00:57.27 4u7D0Pvy
>>92
ごめん、何も考えないでリプライしたがどういう意味?
ZFS でってことなら別に zpool status すりゃどのディスクが死んだのか
出るからそれで十分じゃね?
95:login:Penguin
12/07/24 11:17:39.80 MPgGmg5b
いっつも思うんだけどRAID5とかで死んだディスクがあったとして
それがどのデバイスなのかzpool statusで分かったとして
実際にハードディスクの蓋開いて物理的に取り出すときに
全部同じ会社の物だったら分からなくね?型番で判別できるもんなのか?
96:login:Penguin
12/07/24 11:54:43.05 IoGoPRg5
>>95
普通はポートに合わせてHDDを付ける
97:login:Penguin
12/07/24 12:10:29.40 nIsHj/9g
>>95
URLﾘﾝｸ(forums.ubuntulinux.jp)
98:login:Penguin
12/07/24 12:16:29.14 4u7D0Pvy
>>95
それは >>96 の言うとおりポート順にすればいいし俺はそうしてる
あとバラバラだとしても smartctl とかで S/N は調べられる
見やすい場所にラベルも貼っておいたほうがいいだろうけど
99:login:Penguin
12/07/24 12:23:32.31 dYUyhmty
>>95
仕組みを考えてみてくれｗ
RAID5は一個ディスクが壊れた時交換することを前提にしてるんだぞ。
そうやって冗長性を構築してるんだ。うまく交換できないなら全てが成り立たない。
100:login:Penguin
12/07/24 12:33:12.42 9KUek6bD
RAIDを構成する全てのHDDのメーカと型番を変えれば無問題！！
101:login:Penguin
12/07/24 12:37:46.59 6iiKc8qg
HBA側がminiSASで分岐ケーブルなら大概がSATA/SASコネクタに番号が振って
あるから間違いようもないし。
いまはむしろ6GB/sと3GB/sで混在するオンボードの端子の方が勘違い
しやすいんじゃね?
102:login:Penguin
12/07/24 15:16:26.67 tFIg/b+J
タマの物理的な管理もできない奴がRAID組むなよw
103:login:Penguin
12/07/24 16:38:05.25 GEO4Ipe/
FreeBSDでzfsのホットスペアって自動でreplaceしないの？
自動でならないんでググって見たら他の人もなってみたいで
自分で監視してdegradeしたらreplaceするようなの作らないとダメかな
104:login:Penguin
12/07/24 16:48:34.06 6iiKc8qg
Solarisだと自動でspare指定のデバイスと置き換えやってくれたけど、
そういえばFreeBSDだとどうなるか試してないな。
105:login:Penguin
12/07/25 00:46:35.69 ndJdQG/v
>>94
エンクロージャーがいっぱいある環境で間違えない保証ってある？
106:login:Penguin
12/07/25 00:51:21.75 smt0Kpah
保証ときましたか
107:login:Penguin
12/07/25 01:10:14.63 UUit7ctY
そこは保険をかけてですね
108:login:Penguin
12/07/25 01:37:59.16 r2JW7mqD
保証があるかないかと言われれば、無いですねえ
109:login:Penguin
12/07/25 06:39:00.81 S4heVpB+
アクセスLEDが消灯してるからだいたい分かる。
ツールでステータスLEDを光らせることができるのもあるけど。
あと手でさわって振動してないやつな。
110:login:Penguin
12/07/25 10:15:29.16 uIU5TC7o
ejectコマンドでcdやdvdを取り出すみたいにHDDも取り出せるような仕組みがあればいいんだけどな。
データセンタとかでは既にそういうのありそうだけど。
111:login:Penguin
12/07/25 12:08:32.11 r2JW7mqD
>>110
物理的にHDDが飛び出すのか。
こえーよw
112:login:Penguin
12/07/25 12:25:36.88 Z/LpES06
個体差で元気が良すぎるのとかアリそうで嫌だわ
113:login:Penguin
12/07/25 14:23:24.47 0/dsAC8Y
飛び出すのは円盤だけだから心配しなくていい
114:login:Penguin
12/07/25 17:16:50.35 r2JW7mqD
UMD射出機能か
115:login:Penguin
12/07/27 03:21:21.15 2gyiwu9o
Win/osx/linux（それぞれ最新のもの）で共通して使うことのできる（読み書き操作できる）外付ハードディスクに適したファイルシステムにはどんなものがありますか？メディアファイル置場としての用途を考えています。
自分の知識ではFAT32くらいしか思いつかないのですが、パフォーマンス的にもディスクの効率的にも見劣りします。
他に選択肢ってありますか？
116:login:Penguin
12/07/27 03:35:12.30 9Jct0+4Y
パフォーマンス以前に最大ファイルサイズが4GBなFAT32は問題外
117:login:Penguin
12/07/27 03:48:36.24 HunahTcq
2TのHDDをFAT32でデータディスクとして使ってるけど、書籍スキャンデータを保存してるだけなので問題はないが、
１ファイル辺りの上限よりもディスク全体の容量の上限の方が将来的には問題かな。
ジャーナリングが無い分ディスク容量を最大限使えるし、ディスク障害時サルベージツールも充実してる。
今新規にHDDをデータディスクとしてフォーマットするなら、ext3かなぁ･･･。
ext4でもいいんだけ、Ext2Fsdがext4の全部の機能には対応してないから。
118:login:Penguin
12/07/27 04:07:26.94 M912Io9F
以外にもUDF
119:login:Penguin
12/07/27 05:03:06.35 N5e/xEb+
FAT64
120:login:Penguin
12/07/27 05:04:18.08 E70A0Dqu
exFAT?
121:login:Penguin
12/07/27 18:40:24.18 2cMct7x7
ちょいとageますよ
122:login:Penguin
12/07/27 20:20:08.74 zpI4hBpc
ntfsでいいだろ常考
123:login:Penguin
12/07/27 20:29:23.51 sqrn/X7O
まあwindows使う時点でNTFSしかないと思う
124:login:Penguin
12/07/28 14:41:08.76 4II9ouo5
バターFSでフロッピーディスクをフォーマットしたいです
125:login:Penguin
12/07/28 17:50:01.11 YSSTz/Is
zfsでsamba鯖に最適化するチューニングって何がありますか
zfsのパラメータ調整をググって見るとzfsにあまりメモリを持って行かれないように制限をかけるって言うのが多いんだけど
ファイル鯖なら特に弄らなくてもいいんかな
126:login:Penguin
12/07/28 18:23:06.93 TaCW4HgC
ZFSにsambaか
何故FTPにしないんだろうか
127:login:Penguin
12/07/28 19:38:04.09 YSSTz/Is
>>126
windowsから扱いやすいからですかね
128:login:Penguin
12/07/29 21:43:07.70 U8lScalp
今時FTP鯖はLAN内ですら使わない。
129:login:Penguin
12/07/30 06:50:22.37 b68kzl1O
ext4ってどう読むのですかね。英語圏の人とか。いくすとふぉー？
130:login:Penguin
12/07/30 06:51:27.52 b68kzl1O
無駄な改行入れちゃったごめんﾃ
131:login:Penguin
12/07/30 07:39:25.82 loVBUCO7
テヘぺろ
132:login:Penguin
12/07/30 07:48:42.56 Dcn5cqrq
てへぺろの苛々感は異常ｗ
133:login:Penguin
12/07/30 07:54:09.31 RTw3rMQb
てへぺろ
134:login:Penguin
12/07/30 08:13:20.95 Dcn5cqrq
苛っｗ
135:login:Penguin
12/07/30 13:48:49.99 wWO1cTqS
かわいいは正義
136:login:Penguin
12/07/30 14:30:01.56 Dz1gWYOK
サムドライブ並とな
137:login:Penguin
12/07/31 03:39:50.65 79ga/vr4
どうせテンプレ表現ならてへぺろこつん、まで行かないとイラっとする。
138:login:Penguin
12/07/31 19:33:22.92 xo9C1TjI
Windowsでも2003からシンボリックリンクできたんだけど、smbmountしたら読めなかった
微妙に使いずれー
139:login:Penguin
12/07/31 19:37:18.44 LHI+Ihry
sambaの follow symlinks = yes みたいなオプションはWindowsにはないの?
140:login:Penguin
12/07/31 20:01:54.31 D3Jz/2rU
2003でsymlinkなんざ非公式だもの
141:login:Penguin
12/08/01 02:24:34.49 KzreGFcV
やっぱり次世代型ファイルシステムには、
別ドライブに飛べるハードリンクが必須だとfindを回しながら思った
142:login:Penguin
12/08/01 02:44:51.68 k51UmUoK
bindでいいじゃん
というかlnとbindの使い分けが分からん
143:login:Penguin
12/08/01 10:59:55.40 NDDc4z7t
bind: root権限が必要。起動時にbind状態にしておくにはfstabに書く必要がある。
bindしておけばchrootの中から外にアクセスしたりも可能
ln: root権限必要ないしfstabに書かなくてもいいからほいほい作れる
144:login:Penguin
12/08/01 17:06:18.60 xt0X7jSl
FTPという懐かしい響きに耳を傾ける時がやってきたのだ
145:login:Penguin
12/08/04 01:36:21.37 Qx9zcz2z
SSDスレより転載。XFSを使ってるな。
910のベンチ取ったやつがいるな
はえー
Intel SSD 910 800GB のベンチマーク
URLﾘﾝｸ(blog.nomadscafe.jp)
146:login:Penguin
12/08/04 17:16:05.01 o4u+/A6C
XFSへの信頼が私の希望を支えている。
私は信じようと思う。
自らの苦しみを救われたが故に、
同じ苦しみにある人々のために、
働くことを惜しまないXFSがたくさん見いだされるであろう事を。
147:login:Penguin
12/08/04 18:41:56.74 uDyMCS8E
次組むnasはいつ死んでもいいようにRAID5か6でLVM上にXFSにして
一定期間アクセスなけりゃ対象パーティションククリーニングするcron動かしておこう
148:login:Penguin
12/08/04 22:51:39.63 wWdfQzo5
で、中身はエロ動画。
149:ないだろうな
12/08/06 21:11:09.48 o+HWIjCt
USBで繋ぐHDDアダプターで2TB対応していない奴で3TBを認識させる方法ってある？
セクターサイズが4KBなら2TB上限ってことはありえないと思うんだけど。
150:login:Penguin
12/08/06 21:31:37.70 UVF/tqBm
無いと思います。
URLﾘﾝｸ(sunnyone41.blogspot.jp)
URLﾘﾝｸ(www.century.co.jp)
151:なるほど
12/08/06 21:40:44.94 o+HWIjCt
つまりGPTでフォーマットして対応したパーティションツールでも
古いUSB2.0の多くの変換チップは4kb物理セクターに対応していないって
ことか？
物理セクターが4kbならセクター数の上限が2tbと計算されるわけないだからね。
これってUSB2.0の規格で2TBの制限をしている記述を見つけられなかった。
つまりUSB3.0対応の新しい変換チップならUSB1.1/USB2.0動作であっても
2TBより大きなGPTで繋げることはできるって話に思える。
152:login:Penguin
12/08/07 09:51:35.96 mFxqv+lE
読み書きはSCSI由来だもの
Read(10)/Write(10)にしか対応してないブリッヂチップにRead(16)/Write(16)送ったってそれをATAコマンドに変換してくれるわけない
下二行はその通りだよ
ホストチップやケーブルがそのうえでどんなコマンドが流れていようと知ったこっちゃない
153:login:Penguin
12/08/07 10:00:27.87 Q5lw2EvA
>>150
＞URLﾘﾝｸ(sunnyone41.blogspot.jp)
わざわざ貼る価値のある記事に見えないんだが･･･
アフィ目当ての本人？
154:login:Penguin
12/08/07 16:20:23.87 HDT3d3au
>>153
価値はともかく、そのブログにアフィは見あたらんのだが。
どこに広告があるのよ？
155:login:Penguin
12/08/08 01:23:08.48 uudX+7lg
>>152
昔2048byte sectorのSCSIのドライブがあったがSCSIで4kに対応していないってこと？
松下製品
USB2.0のSCSIエミュレーションがSCSIの一部はサポートしていなかったってこと？
たしかAdapticのUSB経由のSCSIアダプターで2kセクターのドライブで読み書きは
問題なかったんだけどね。
156:login:Penguin
12/08/08 04:14:12.26 WaqfcOqv
というか現行のHDDは物理4KBセクタでも論理セクタは512Bの製品しかないからあんま関係無いような。
157:login:Penguin
12/08/08 08:42:52.91 uMrm0wh2
>>155
物理/論理セクタサイズなんてお前の問題に関係ねーよハゲ
158:login:Penguin
12/08/10 19:56:07.97 HtVfNV4D
物理セクターが1024バイト同時に論理(OSのIO)も1024バイトもあるぞ。
無知な奴はこの程度の知識もしらないようだけどな。国産機
159:login:Penguin
12/08/10 20:48:09.86 NVED6avE
無知だっていいだろ。
その辺をよろしくやってくれるのがLinuxなんだから
160:login:Penguin
12/08/11 20:53:05.90 6m1hNuKe
OSはセクターサイズとか余り関係ない、巨大なサイズでも対応している。
関係あるのは物理層で装置をアクセスするようなTOOLである
フォーマットツールやらFDISKなどの装置に直節アクセスするツールの対応だけです。
BIOSも512バイト以下しか対応していないのがあるのでブートに使う場合は注意
となる。そういう問題じゃないとCD-ROMすら512Byte/Sectorじゃないのでアクセス
出来ないことになってしまうわけです。512byteというのは専用のその手の
ツールを出さないから必要なのであって別に個々に対応すればいいだけのことです。
161:login:Penguin
12/08/11 21:06:00.46 o+O6Wvt6
「TOOL」がイラっとくる
162:login:Penguin
12/08/12 00:58:07.17 cg/r2IE3
そんな神経質な奴がむかつく。
163:login:Penguin
12/08/12 01:11:01.29 k2lVkNLV
そんなお前がむかつく。
164:login:Penguin
12/08/12 01:14:01.86 ji5+pEzu
反応しちゃうお前らがむかつく
165:login:Penguin
12/08/13 10:50:55.36 N/Dr2AUx
/をxfsからext4に変えたら快適になった
xfsの時はアップデートとかでファイルアクセスが多くなると頻繁にプチフリーズしてたけど
(dmesgでタイムアウトしたのかエラー吐いて死んでた)
ext4はそんなことはなかったぜ
166:login:Penguin
12/08/13 17:38:30.32 E//ruVVI
>>165
/以外はXFSのままなのか？
OSもハードも何もわからん kwsk
167:login:Penguin
12/08/13 20:02:05.21 GDUGdsZV
どうみても
xfs が barrier=1 (これがデフォ) で ext4 が barrier=0 (これがデフォ) ですありがとうございました、
でしかない。
アップデート(アクセスだけでなく消去が多い)で遅くなるんだから。
168:login:Penguin
12/08/13 21:32:20.30 N/Dr2AUx
>>166-167
xfsの/はnobarrier,logfs=8,relatimeでマウントしてた
ext4はdefault,relatime
どちらもubuntu12.04i386で32bit
/以外は/boot以外xfs
169:login:Penguin
12/08/13 21:34:49.64 N/Dr2AUx
s/logfs/logbufs/g
170:login:Penguin
12/08/14 09:38:46.27 3Fu4n6Fm
>>167
デフォじゃねえよハゲ
171:login:Penguin
12/08/14 09:46:24.46 PxCbp1bD
2.6.30以降はrelatimeがdefaultになってるのでは？
172:login:Penguin
12/08/19 03:26:33.21 NblHKOa8
btrfsの自動修復すげえ
URLﾘﾝｸ(green-rabbit.sakura.ne.jp)
173:login:Penguin
12/08/20 04:00:59.91 POUKKiWk
ZFSにも自動修復あるんじゃなかったっけか。
174:login:Penguin
12/08/20 04:14:52.72 EEvP5yt2
>>170
ハゲはデフォだろ
175:login:Penguin
12/08/21 15:01:50.55 eM09EP6E
マジレスすると赤ちゃんにも髪の毛は生えてるんじゃなかったっけ
176:login:Penguin
12/08/21 15:18:15.94 wqb4ipul
いつのバージョンの話だよ。
髪の成長機能なんてとうの昔に削られとるわ。
177:login:Penguin
12/08/21 15:52:44.69 jxiFFyWU
リファクタリングと言え
178:login:Penguin
12/08/23 18:14:05.98 1lMlFTOu
発毛システム総合スレその１５本目
179:login:Penguin
12/08/23 21:03:51.29 hIv7rQY4
髪×３ファイルシステム
180:login:Penguin
12/08/29 09:00:02.84 UR6Q908w
すっかり忘れてましたが、ZFS-0.6.0-rc10 公開されてました。
このバージョンからDKMSに対応したみたいです。
181:180
12/08/29 13:18:23.87 UR6Q908w
spl-modules-dkmsとzfs-modules-dkmsをインストールしておくと
カーネルアップに対応して、うまいこと動くみたい。（CentOS 6.3）
zfs-modules-dkmsのインストールの時にspl-modules-dkmsの依存で
怒られるので仕方なく--nodepsオプションでエラーを回避する。
182:login:Penguin
12/08/30 02:35:23.64 uq2SalLE
ppaから入れてるubuntuでは前から対応してた気が＞dkms
183:180
12/08/30 08:28:59.12 k02CpNtw
>>182
こちらはソースからコンパイルしてrpmパッケージを作ってます。
VirtualBoxで開発環境と試験環境を作り、試験環境で問題が
ないなら、実環境にrpmインストールしてますが、今回の
dkmsはインストール時にエラーが大量に出たり、依存関係で
zfsのdkmsが入らないとか、危険な香りがするので、今回は
見送ることにしました。
184:login:Penguin
12/08/30 22:47:53.19 uq2SalLE
>>183
結構不安定な感じですね。まぁrcだしそんなもんか。
ちなみにrc10だと# zfs rename -rができないというバグがあった。自動バックアップスクリプト書いてたら気付いたｗ
ubuntu用のdaily build(0.6.0.72)ではもう直ってるのでrc11では直ると思うけど。
185:login:Penguin
12/09/05 16:37:20.48 32C94rOj
URLﾘﾝｸ(twitter.com)
>>25にkosakiタソが反応している件について、一言おねがいします。
186:login:Penguin
12/09/08 16:57:56.32 FMGje22I
ZFSでいいじゃん
187:login:Penguin
12/09/08 19:10:55.58 cTMGQ1Bw
ZFSアクセラレータチップって出ないかな
188:login:Penguin
12/09/08 19:48:31.82 ZPk2Vx7A
zfsでいいよな
189:login:Penguin
12/09/08 20:44:42.62 FMGje22I
ここに至ってext4推す人ってなんなの？
ZFSを叩き潰したい人なのかな？
それとも単純にアンチLinux派の人とか？
190:login:Penguin
12/09/08 20:47:25.77 D8s+KTbM
>>189
へ？
191:login:Penguin
12/09/08 20:56:46.55 F6ioY5H4
ここはLinux板だぞ
192:login:Penguin
12/09/08 20:57:45.30 Ccehe50P
zfsって素晴らしすぎるんだけど
メモリー食うしロースペに優しくない
ext3、4が無難
余裕あったらLVMとか
193:login:Penguin
12/09/08 21:02:29.16 F6ioY5H4
raidzなんかはいいなと思うけど
raidなしでzfsをあえてlinuxで使うほどでもない気がする
194:login:Penguin
12/09/08 21:02:31.09 TzN7fYqi
LVMは起動に時間がかかり過ぎる
lvm.confのfilterでsdaしか指定していないはずなんだけど
LVM領域の認識だけで1分以上かかる。
スナップショット機能のためだけにLVM使ってるけど正直辛かったので
この前買ったマシンにはbtrfs入れてやった。
195:login:Penguin
12/09/08 21:08:09.85 lNrpvBvE
エンプラ用途以外でLVMなんかあほ過ぎる
エンプラですら最近じゃ敬遠されてるけど
196:login:Penguin
12/09/08 21:23:32.42 tgt4qdr7
XFSなきUbuntuか、あるいはUbuntuなきXFSか
そのいずれを持つべきかの決断を迫られたならば
私は一瞬のためらいもなく後者を選ぶであろう
197:login:Penguin
12/09/08 21:49:50.34 DxPXyXp5
ロースペに厳しいって、5年まえならまだしも、今やzfsを使いたくなるような
HDDを使う機種で問題になるようなスペックってあまりない気がするけどなあ。
198:login:Penguin
12/09/08 23:45:58.62 f3UqASFf
luksで暗号化した上にlvmしてその上にxfsでフォーマットしてるは
199:login:Penguin
12/09/08 23:49:41.60 FMGje22I
ZFSの暗号化機能はよ
200:login:Penguin
12/09/09 01:16:26.36 LKCbpbid
チラシの裏
btrfs や zfs の安定を待つのもめんどくさいんで、
ストレージは xfs、あとは全部 ext4 に一本化した。
次の Ubuntu LTS が出るころにでもまた
fs 周りをチェックするとしよう。
201:login:Penguin
12/09/09 13:49:28.82 Wmo2c+nU
tune2fsでmetadata checksum有効にした人いますか？
202:login:Penguin
12/09/09 23:37:33.51 DKfUryqw
バターFSはドッグフードとして食ってるけど、食当たりになったらどうすればいいかな。
203:login:Penguin
12/09/10 08:40:57.21 Mr/WNBTq
zfsってZettabyteFileSystemのくせに最大16ExaByteなんだな
204:login:Penguin
12/09/10 09:49:52.40 VhLbhvpO
>>203
fsの仕様と実装との差異かな。ext4も16GBの壁がkernel 3.2.0まであったわけだし。
205:login:Penguin
12/09/10 10:12:36.18 H3nhObG0
小さ過ぎィ！
206:login:Penguin
12/09/10 12:38:16.43 kbI4D03N
ZFSはプールの最大容量がZB級じゃなかったっけ？
16EBは1ファイルの最大サイズとかだったような。
207:login:Penguin
12/09/10 12:45:34.14 rlrbxCyN
>>204-203
ワロタ
208:login:Penguin
12/09/12 11:06:01.32 iUU38R60
FreeBSDだけどzfs rename -r hogeしたら止まってしまってOSリブートするしかなくなる
-rいれなければ大丈夫なんだけど
209:login:Penguin
12/09/13 19:17:18.60 dAOT01mS
ファイルシステムのまずさの原因は、ほとんどの場合ファイルシステムにあるのではなく自分の内部にあります。
まず自分の心を点検してみなさい
210:login:Penguin
12/09/15 19:27:33.63 HSwaCxdG
もっとファイル名長問題を盛り上げてもいい頃
211:login:Penguin
12/09/15 19:31:27.14 mKEfZUqM
本体8文字拡張子3文字あれば十分
212:login:Penguin
12/09/15 19:56:17.30 HSwaCxdG
じゃあMS-DOS 2.11で充分かw
213:login:Penguin
12/09/15 20:08:39.48 d8oSF6Lw
さすがに拡張子３文字はきびしいです＞＜
214:login:Penguin
12/09/15 20:25:55.00 GLwzh97N
シェルスクリプトのTempファイルの拡張子、そこを狙って5文字当ててたわw
215:login:Penguin
12/09/15 22:04:43.19 kMdyr3Th
debとかrpmファイル余裕で8文字超えるじゃん
パッケージ名とバージョンとアーテキチャと拡張子で
216:login:Penguin
12/09/15 22:07:41.40 901WsnWo
バージョンやアーテキチャをファイル名に折り込むってのも前時代的だよな
217:login:Penguin
12/09/15 22:09:34.86 hLipm4zA
でも分かりやすくていいよな
218:login:Penguin
12/09/15 23:27:10.88 2w6S69rf
>>216
今更リソースフォークですか？
219:login:Penguin
12/09/16 00:13:30.38 ZfQHcMF4
WinFSです
220:login:Penguin
12/09/16 01:02:10.63 4btd2o59
ファイルシステムで管理するんじゃなくて、ファイルに付けないと流通させられないが?
221:login:Penguin
12/09/16 03:07:34.70 2bFAxxke
>>216
ファイル名って言うのは人間の為につけてるんだよ
222:login:Penguin
12/09/16 13:40:44.67 iBo2oXbC
ファイル名長でReFSに置いてかれるな
223:login:Penguin
12/09/16 21:19:02.64 d0iroRdT
>>221
rpmの場合ファイル名にアーテキチャ入ってないとエラーになっちゃう
224:login:Penguin
12/09/16 23:35:01.95 aQSQhxQ2
あーてきちゃ
225:login:Penguin
12/09/17 01:47:17.81 iLK3tHiB
あーくてきくちゃ
226:login:Penguin
12/09/19 13:01:57.64 jMFiRUr+
>>223
リネームして短くしてもエラーにならんぞ？
227:login:Penguin
12/09/20 10:41:13.85 1Iimwh+c
ここの人たちは、拡張子は必要って思ってるんですか？
今だとウイルスの偽装やら、デメリットの方が大きいと思うんですが。
228:login:Penguin
12/09/20 10:49:54.17 DmjFM4sU
>>227
ファイルシステムと拡張子になんの関係が
229:login:Penguin
12/09/20 11:22:01.86 r+uTrKuo
拡張子ないとファイルの種類を区別できないでしょうが。
230:login:Penguin
12/09/20 11:51:45.29 GfP9IUJv
>>229
マジックナンバー見ればいいだろ
231:login:Penguin
12/09/20 11:56:11.57 eCd7MSfu
Linuxでウイルスの偽装とかなんのことやら
232:login:Penguin
12/09/20 12:14:54.10 iZHvI+wD
・拡張子表示しないファイルマネージャーがない
・「ウイルスの偽装やら」以外のデメリットが提示されていない
233:login:Penguin
12/09/20 12:47:11.63 kpH7pJ3i
「(合法)子猫と子犬が仲良くじゃれあう動画.mp4 .sh」とかじゃねーか。
234:login:Penguin
12/09/20 13:33:58.15 iZHvI+wD
pythonスクリプトかcのソースかマジックナンバー見たら分かる訳じゃないしね。
vimやemacsで読み込んだ時のfiletype判定とか大変じゃね?
235:login:Penguin
12/09/20 13:39:26.47 DmjFM4sU
>>229
ファイルシステムはファイルの種類を区別はしないんだが。
ファイル名はただのバイト文字列を格納してるだけ。
拡張子うんぬんは上のレイヤの話。
236:login:Penguin
12/09/20 15:01:02.03 GlgYHoB2
ファイルシステムでファイルの種類を区別しちゃいけないってこともないけどな
拡張子は普通はシェルで取り扱う
237:login:Penguin
12/09/20 15:22:59.98 r+uTrKuo
画像ファイルだって、他人に見せていいものと自分だけで楽しみたいものがあるだろ
そういう区別をファイルシステムが覚えてくれれば、いろいろ便利だと思うんだけど
238:login:Penguin
12/09/20 15:24:56.97 GlgYHoB2
オールドスタイルなパーミッションではダメなのか？
239:login:Penguin
12/09/20 15:26:32.02 iZHvI+wD
フォルダ分けじゃ駄目な理由が特にないけどな。
一応現状でも拡張ファイル属性にいろいろ格納できるんだから
やりたければアプリ側でそこにタグでも何でも格納すればいいんじゃないの？
240:login:Penguin
12/09/20 15:38:57.79 8pt4oAZI
>>233
(合法)子猫と子犬が仲良く... .sh
に省略されるだけで拡張子はわかるだろ。
何か問題が？
241:login:Penguin
12/09/20 15:42:13.64 iZHvI+wD
昔のWIndowsのファイルマネージャーだと空白が長すぎたり改行が含まれてたりすると
最後の.shが表示されなかったんだよ。
242:login:Penguin
12/09/20 15:52:22.88 eCd7MSfu
だから？
243:login:Penguin
12/09/20 15:58:12.88 iZHvI+wD
「(合法)子猫と子犬が仲良くじゃれあう動画.mp4 .exe」
ってファイルを動画だと思ってダブルクリックして
ウィルス感染してた時代もあったってことだよ。
244:login:Penguin
12/09/20 16:01:34.79 iZHvI+wD
いや勿論Linuxだとファイルマネージャーなんか使ってる人少ないから
まずひっかからないだろうし
そもそもroot権限奪わないといけないから大変だろうけど
少くとも>>227の言ってたウィルス偽装ってそういうことだろ。
そもそもファイルシステムの話とは関係ないから俺は降りるかな。
245:login:Penguin
12/09/20 16:02:58.34 IiBf+HaE
Linux板でWindowsの話をしている馬鹿が居る
246:login:Penguin
12/09/20 19:46:19.20 Hho4w2j8
>>234
> pythonスクリプトかcのソースかマジックナンバー見たら分かる訳じゃないしね。
いや、#! /usr/bin/pythonなら、/usr/bin/pythonで実行するから、
上で話題になっているような、想定してない処理プログラムを走らせる攻撃は受けない。
247:login:Penguin
12/09/20 19:56:03.96 SgvB4CEX
Linuxってある程度は拡張子なしで判別できるんだったらやばいじゃん
Winなら拡張子命だから猫.mpeg.exeとかしなあかんけど
Linuxとかなら
中身実行ファイルの猫.mpeg
で自動的に実行ファイルと認識するから拡張子偽装する必要なくなる
248:login:Penguin
12/09/20 20:02:29.82 Hho4w2j8
ダウンロードしただけでは実行できないし、
更にその上最近はSELinuxでダウンロードしたファイルは特別視されてるし。
>>247
Linux使ったことあるの?
249:login:Penguin
12/09/20 20:04:59.50 u0ceN304
xフラグ（実行フラグ）が立ってない場合、インタプリタを指定しないとシェルスクリプトは実行されないよなぁ
250:227
12/09/20 21:56:52.32 1Iimwh+c
>>215 >>221 を受けて、拡張子は誰も触れないんで聞いてみたんですけど。
拡張子のメリットって何かなあと。
偽装にあまり突っ込まれると困ります。
251:login:Penguin
12/09/20 22:07:53.32 mS5yHgLG
拡張子だってファイル名の一部、ということを忘れてなければ>>221がそのまま答えだと思うが・・・
252:login:Penguin
12/09/20 22:57:56.63 jqOim1D1
>>240
その考え方はマズイだろ。
ファイルの種類を目視確認するから偽装に騙されるんだよ。
ファイルの種類は取り扱うシェル（と同等のライブラリ）に判別させろよ。
一時期 Windows でセキュリティのために拡張子を表示しろといかいう馬鹿が沢山いたが、
エクスプローラの詳細表示でファイルの種類を表示する方が正解。
253:login:Penguin
12/09/21 00:01:59.04 Pe5+z/rC
古臭い人間だが、日常的なファイル変換するのに make 使ってる
コマンドのルールを記述するのに拡張子ないと困る
テキストファイル(org)を PDF 化したり、数値データ(csv)として統計処理したり、ソース(c, cpp)からプログラム作ったり
254:login:Penguin
12/09/21 00:03:55.87 VLw/MbBu
だーかーらー拡張子の話はスレ違いだろうが。
他でやれ。
255:login:Penguin
12/09/21 07:12:56.67 OCWNaOVo
拡張子スレなんてあるの？
256:login:Penguin
12/09/21 07:27:03.61 OUsfHU4r
拡張子スレ自体は10個以上あるな。
257:login:Penguin
12/09/21 12:23:10.26 xgzSXJRY
拡張子はファイル名とは違う「ファイル種別」を示すものとして、
ファイルシステム側で特別扱いすべきものだろ。
現行のファイルシステムがデフォルトで対応できないなら、
少なくとも拡張子をファイル種別として記録できるように
マウントオプションで選択できるようにすべき
258:login:Penguin
12/09/21 12:36:23.68 JWa78uTU
わざわざ拡張子のために別領域用意して何か嬉しいことあんの？
259:login:Penguin
12/09/21 13:30:49.56 b44JPpzD
拡張子なんぞ使わなくても拡張領域というものがあるんだからそっち使えや。
260:login:Penguin
12/09/21 13:51:47.80 bxodQecC
拡張子よりファイル名長問題の話題しようぜ
261:login:Penguin
12/09/21 14:11:25.64 aMFGpFYa
>>257
拡張子はどうでもよいが、ファイル名とは別にどのような種別のファイルか
記録する方法はあってもいい。
ネイティブなファイルシステムに、その方法がないのはUnixだけだけどな。
262:login:Penguin
12/09/21 16:04:32.22 0a003z4K
リソースフォークの復活か。でもあれも別にファイルシステムの機能じゃないな。
263:login:Penguin
12/09/21 16:13:49.40 d7ovAYiG
>>260
あんまり長いファイル名許すと、それに頼った運用する連中が出てきて
その被害に巻き込まれそうだから今のままでいい
>>261
fileコマンドで何が不満なんだ
264:login:Penguin
12/09/21 16:34:52.78 clUu8XMM
VIVOより美味いのはVIVOだけだけどな
265:login:Penguin
12/09/21 18:34:43.43 wNu+jRMu
>>261
ext系に有る filetype って何のために存在するんだろうな
266:login:Penguin
12/09/21 21:09:05.21 gxBeBj6C
今は拡張子なんかより、大文字小文字を区別するかどうかって問題が大きくなってきているような。
267:login:Penguin
12/09/21 21:13:42.72 JWa78uTU
大文字小文字区別するかどうかはOS側の問題で
ファイルシステムは大抵区別するはずだけど。
そういやWindowsって今でもNTFSは大文字区別するけど
WindowsのOSは大文字小文字区別しないって仕様なんだろうか。
268:login:Penguin
12/09/21 21:28:59.23 gxBeBj6C
OSかファイルシステムかってのはどういう区別なんだ？
ファイラはOSって区分なんだろうか？
Mac OS Xの場合、カーネルのファイルシステムドライバが、
HFS+ではcase-insensitiveで、UFSやNFSでは、case-sensitive。
ただしFinderが別途case-insensitiveにやってる。
だからCUIだとファイルシステムごとに違う。
269:login:Penguin
12/09/21 21:55:32.38 yU31tBlI
OS=Opereting System
ファイルシステム=File System
270:login:Penguin
12/09/21 22:19:08.79 wNu+jRMu
obcaseinsensitive
271:login:Penguin
12/09/21 22:26:27.59 4ylF6bk1
MAC のファイル名の濁点問題も健在だっけ
272:login:Penguin
12/09/22 00:11:48.04 PpWMd5yJ
URLﾘﾝｸ(key2.jp)
こんなの見つけちゃったけど、もう作っちゃったzfs poolは作り直すしかないの？
はぁ．．．
273:login:Penguin
12/09/22 00:28:56.98 xakY400e
ファイル名の文字数はwindows並になった？
なってなかったら一年後また来る。
274:login:Penguin
12/09/22 02:01:09.05 KfI4Q/7Y
>>272
macからnfsで接続なんてことしてなけりゃ関係ないんじゃない。
275:180
12/09/22 08:36:03.83 9+pTNW3t
>>272
Netatalkをインストールすれば問題ない。
3.0から設定が簡単になったので、試してみれ。
276:login:Penguin
12/09/22 09:20:09.04 M/DcOAHw
>>263
人間のためのファイル名じゃんw
NTFSでファイル名を長く使えてどんな被害があるの?
277:login:Penguin
12/09/22 16:18:13.17 LO7y59vv
>>276
ファイルサーバにバックアップしたい時にファイル名で引っかかる
278:login:Penguin
12/09/22 16:30:34.03 PpWMd5yJ
ファイル名長いとtarに格納できないんだっけ
279:login:Penguin
12/09/22 17:11:48.34 AMpPKnTT
大文字小文字を同一視するファイルシステムって、ラテン文字やキリル文字やギリシア文字の大小も律儀に同一視してくれるの？
280:login:Penguin
12/09/22 17:29:34.03 13EzWjao
>>279
一応こんなテーブル持ってます。
URLﾘﾝｸ(opensource.apple.com)
281:login:Penguin
12/09/22 17:44:43.19 F/d1hvZ+
>>277
Linux側でどうにかファイル名ながくできないのか？
282:login:Penguin
12/09/22 17:48:50.42 13EzWjao
安易に変えるとLinux内でもバージョン間でファイルのポータビリティなくなるからな。
283:login:Penguin
12/09/22 17:48:58.82 LO7y59vv
>>281
しょばい話だけどNTFSをLinuxのext3でsamba共有使用とした時に
sambaのファイル名長に引っかかったと思う
sambaで解決してもext3でも引っかかるんじゃないかな
とりあえずサーバ側のディスクをiscsiでwindowsから使ってる
284:login:Penguin
12/09/22 17:55:44.77 AMpPKnTT
>>280
詳しく見てないけどU+1E9Eには未対応だろうね
285:login:Penguin
12/09/22 19:46:40.44 xakY400e
273です。
まだだったか。
286:login:Penguin
12/09/23 02:23:11.47 gJB1mzz5
>>272
その記事は半分嘘。normalizationで指定した正規化方法でファイルを記録してくれるわけじゃなくて、
単にFSにファイル名比較の要求がされたときに設定した正規化を行って比較するだけ。
要はformCと設定してNFDなドラえもんを書いてもNFDで記録されるが、NFCなドラえもんを書こうとしたときに同名ファイルが存在してると返してくれるって動作。
>>275の言うとおりnetatalkに任せておけばそうそう問題は起きないと思う。
ZFS+netatalkで個人的に試した範囲だとcasesensitivity=mixedを忘れた時の方が痛かった気が。
287:login:Penguin
12/09/24 19:24:33.87 BTwpUGaW
URLﾘﾝｸ(access.redhat.com)
＞ただし、 リンク数が 65,000 を越えると 1 にリセットされ増加しなくなります。
ってどういう動作なんだろう
288:login:Penguin
12/09/24 19:40:48.87 Ny4350Xt
リンクカウントって>2だから、1だと65000>を意味することにするんでしょ?
struct statのst_nlinkが16bitの互換性とサブディレクトリを65000以上作れることを、
回収できなくなることのデメリットよりも重視するということ。
289:login:Penguin
12/09/24 20:36:04.02 ntsLnrZa
回収できなくなるってどういうこと？
290:login:Penguin
12/09/24 20:46:40.60 Ny4350Xt
サブディレクトリをunlinkしても親ディレクトリのst_nlinkは1(実質∞の意味)のまま。
..の事知らないと何のことかわからないかも。
291:login:Penguin
12/09/24 20:53:25.94 Ny4350Xt
unlinkしても→rmdirしても
# 別スレでUnix V7のこと話していたからw
292:login:Penguin
12/09/24 21:01:33.25 ntsLnrZa
「回収できなくなる」の意味がわからなかった
「回収できなくなる」とはどういうこと？
293:login:Penguin
12/09/24 21:03:32.35 Ny4350Xt
ファイルシステムは、リファレンスカウントのガベージコレクションやってる。
294:login:Penguin
12/09/24 21:41:52.76 ntsLnrZa
もちろん nlink の話題で、デメリットとしての「回収できなくなる」を読めば、恐らくどこからも参照されないディレクトリが残ってしまい消すことができないと言っているんだと予想できる
しかし、コードを読んでも ext4 の rmdir は消したいディレクトリが空なら直接 nlink をゼロにするからnlinkの管理が適当でも正しく動作するし(1)、
実際に65000を越えるサブディレクトリを作ってみてnlinkが1になることを確認してから消しても、容量は元に戻り正しく消せたようだ(2)
そうなると「回収できなくなる」には、僕の理解とは別の意味があるんじゃないかと色々考えて、結果「どういうこと？」と聞くわけだ
にもかかわらず、質問に答えずに .. がどうとか、リファレンスカウントがどうとか別のことを言うのは、よくない
質問には正確に答えるべきだ
もちろん、僕の能力が低いせいで(1)の理解が間違いだったり、(2)が正しい実験ではなかったかもしれない
また、別のバージョンでは挙動が違う可能性は残っている
そもそも、「回収できなくなる」には別の意味があったのかもしれない
そういう色々な可能性が考えられるから、「回収できなくなる」とは何を意図しているのか、正確に知りたかった
295:login:Penguin
12/09/25 01:46:47.91 g8ftd0U7
これは質問が悪いだろ。
296:login:Penguin
12/09/25 14:51:59.61 hzHYhHyn
質問の仕方は悪いが抽象的なことして言ってない回答者も馬鹿
297:login:Penguin
12/09/25 14:59:20.83 MhTNZXB9
んじゃ答えてあげてよ。
298:login:Penguin
12/09/25 15:19:24.18 7mHujUYI
ディレクトリがハードリンクできる世界からタイムスリップしてきたとか。
299:login:Penguin
12/09/25 15:56:32.40 ie6CmTzc
ちがうだろ、パルスのファルシのルシがパージでコクーンだろ
300:login:Penguin
12/09/27 18:19:53.21 5QedY1DW
>>298
ln -d
301:login:Penguin
12/09/27 18:52:09.14 d5nghtd2
>>300
そういうことじゃねえだろ
302:login:Penguin
12/09/28 16:19:38.60 LQL56AZa
窓から放り投げろ
303:login:Penguin
12/10/03 20:02:48.65 OhisapLS
いやそもそも nlink ってのが何なのか……
304:login:Penguin
12/10/04 23:05:12.99 lFlv+tKp
URLﾘﾝｸ(lkml.org)
JFSにtrimが
305:login:Penguin
12/10/05 23:30:23.27 Vea7jgnN
jfs使いとしては喜ぶべきことだな。
reiser4が新しいカーネルにマージされるらしいね、こっそり開発続いてたのね。
306:login:Penguin
12/10/06 01:30:41.44 SkMTlz/z
まじかよ
いつのまにこんなページができてたんだ
URLﾘﾝｸ(reiser4.wiki.kernel.org)
307:login:Penguin
12/10/08 15:47:33.65 dFkmzqRr
草葉の陰でHansも喜ぶだろうな。
308:login:Penguin
12/10/08 18:31:03.39 5MeFU1N8
死 ん で ま せ ん
309:login:Penguin
12/10/08 18:40:10.87 S45asaXB
>>307
檻の中で
のまちがい
310:login:Penguin
12/10/08 19:27:40.22 GDmtR82r
>>307
若草の茂み に見えた。
311:login:Penguin
12/10/08 20:08:25.10 qjMSA1BQ
スレ
どうしてUbuntuは衰退したのか？
ｽﾚﾘﾝｸ(linux板:207-番)
でやりとりしていて疑問に思ったので教えていただけませんか。
GParted(Ubuntu12.04LTS 日本語Remix LiveCD)なんですが、
200GBのNTFSパーティションを右に100MB移動させるとき、
200GB全てを右に移動させているんじゃないかと思われるほど時間がかかりました。
パーティション先頭100MBにあったファイルを、新しく拡張される後端側の
空き領域に移動させて、それに合わせファイル管理情報を更新するだけで
良いと思うのですが、ダメなのでしょうか?
312:login:Penguin
12/10/09 01:40:18.33 7vUOMS0+
ダメでしょう
313:311
12/10/09 01:53:46.10 xUr78a+v
>>312
そうですか。
例えば300GBのパーティションを200GBに縮小するとき、後端100GBの場所にあった
ファイルは縮小される200GBの範囲内に移動されますよね。
それと同じように、パーティション変更後アクセスできなくなる場所にあるファイルは
変更後でもアクセスできる場所に自由に移動させることができるものだと思っていました。
314:login:Penguin
12/10/09 03:53:08.01 GYJBsMSY
その方法は新しい方の空き領域が足りなかったら破綻しますがな
まるっと移動するほうが確実
315:login:Penguin
12/10/09 07:15:52.92 ymL2JR8s
>>311
NTFSの実装は知らないけれど、
もしも、パーティション先頭からのオフセットで管理している要素があったら・・・
316:login:Penguin
12/10/09 08:08:37.44 nnyD2+Yn
普通は相対だろ何言ってんだ
317:login:Penguin
12/10/09 10:58:05.80 jHUE7sVE
そもそも、パーティションの先頭にあるのは管理領域だが。
318:login:Penguin
12/10/09 12:03:23.03 vXRMgl1q
MFTがパーティションの真ん中ぐらいに取られてて60%以上縮小できなかったのはいい思い出
319:login:Penguin
12/10/09 12:59:39.11 jHUE7sVE
MFTを拡大するときにMFTのフラグメンテーションが起きて、
それがパーティションの真ん中に来ることもあるね。
320:login:Penguin
12/10/09 14:04:37.36 CKsP2v7A
MFTは意図的に真ん中にくるようになってるでそ。
デフラグすると意味なくなるけど。
てかNTFSはスレ違いだろ。
321:login:Penguin
12/10/09 14:16:17.38 IbxiAjDm
その理屈だとext234,btrfs以外は板違い…
322:login:Penguin
12/10/09 14:20:01.72 nnyD2+Yn
Reiser4「！？」
XFS「！？」
JFS「！？」
XFS「？？」
323:login:Penguin
12/10/09 14:20:44.48 nnyD2+Yn
ZFSって書くつもりが間違えたし
324:login:Penguin
12/10/09 16:10:55.41 kmIlkpwM
実際には期待通り１００Mとちょっと動かしてただけでしたとかないですか
調べる気はないが
325:login:Penguin
12/10/09 17:23:11.63 8QjLalXf
NTFSはLinuxのデフォルトサポートFSだろ
326:login:Penguin
12/10/09 21:20:33.72 CqAL4Ml2
えっ
327:login:Penguin
12/10/10 10:13:54.27 5I1NvHWm
Android関係の話で、最近はUSBメモリをNTFSで使うのがデフォらしいと聞いたときはびっくりした。
328:login:Penguin
12/10/10 10:40:07.76 gsFvCtEe
FAT32じゃないんだ。
329:login:Penguin
12/10/10 10:45:07.24 i4SvHKD1
exFATとか言うの無かったっけ？
330:login:Penguin
12/10/10 10:58:55.37 2fT/Upxm
あったよ。
331:login:Penguin
12/10/10 11:02:45.64 GgqJQq9Q
ntfsでも大抵の環境は大丈夫なんだろうけど
俺は未だにfat32にしてるな。
ntfsはMacOSやLinuxだといちいちntfs-3gでマウント仕直さないといけないし
332:login:Penguin
12/10/10 11:48:24.24 gsFvCtEe
>>331
俺も、USBメモリとかSD(HC)カードとかだと基本的にFAT32だな。
外付けHDDだとext3/4やNTFSにしたりしてることもあるけど。
PC以外のデバイスで読む可能性が大きい場合はFAT32が鉄板かな、と。
333:login:Penguin
12/10/10 12:04:18.33 l0NrRCCs
>>330
exFATがUSBメモリ用途のFAT32の後継になるもんだとばかり思ってた
MSはそのつもりで作ったんでしょ？
>>331-332
最新情報を把握してないんだけど・・・・
ntfs-3gって今は十分な信頼性あるのかな？
LinuxとWindowsで読めて1ファイル4GB以上OKなファイルシステムでずっと悩んでる
Ext2FsdのExt4サポートって、実用上問題ないレベルに達したのだろうか・・・
もう1年以上アップデートしてないみたいだし・・・
とりあえず今はext3を共用用途で使ってるんだけど、できればNTFSかext4に移行したい
334:login:Penguin
12/10/10 12:25:43.79 CD0ab8oM
UDFの出番
335:login:Penguin
12/10/10 12:28:09.60 gsFvCtEe
>>333
十分な信頼性があるかっていうと、ちょっと分からないけど。
個人的には、内蔵HDDのWindowsとの共用領域はNTFSにしちゃってるな。
マウントしている時にカーネルが刺さったりすると、再起動してもntfs-3gがエラーを吐いてマウントできないことがある。
そうなるとlinux側だけでどうにもならなくなって、Windows側でchkdskが必要になることがある。
本当に稀だけど。
336:311
12/10/10 17:29:04.85 yPSAXVKc
>>311です。
皆さんレスありがとうございます。
>>324
8.0GBのNTFSパーティションで試したのですが、
・縮める時は、その分だけのファイルを移動させているようですぐに終わりました
・右、左に移動させるときは、全てのファイル(セクタ(?))が移動されるようです
色々調べたり皆さんの書き込みから、
NTFSの仕様が完全に公開されていなくて、GPartedはMFTのパーティション内オフセット位置を
変更(MFTを移動)する操作が出来ない。だから、確実な「全体移動」をする。
と考えています。
337:login:Penguin
12/10/10 20:52:27.75 v385fBlC
遅ればせながらZFS Linux Native RC11が出てましたね。
特に問題なく使えています。
いつになったらRCが取れるんだろ。
338:login:Penguin
12/10/10 23:27:04.84 +ZrJmI38
win共用のusbメモリとか随分前からntfs一択だな
339:login:Penguin
12/10/11 00:01:58.07 tHQ9bcc5
でも、USBメモリとかは、暗号化がついたFSじゃないと使えなくない？
340:login:Penguin
12/10/11 00:03:55.44 WS6FvsE5
大切なデータはもちろん暗号化したFS領域にいれてるよ。
全部暗号化しちゃうとデータの受け渡しにすら使えないし。
341:login:Penguin
12/10/11 09:33:33.91 V5vBYLQ+
暗号化すると漢字やカタカナのフォルダ名は文字化け起こしてしまうけどな。
342:login:Penguin
12/10/11 09:49:29.10 /wU9AuKr
どこの糞ソフトだよ
343:login:Penguin
12/10/11 16:25:44.56 GYQK0rbP
>>336
NTFSの先頭はMFTって決まってるんだって。
何がどこにあるかは全部MFTに入ってるのに、
MFTの場所が決まってなかったらファイルシステム読めないべさ。
344:login:Penguin
12/10/11 20:34:32.36 Wk88iD1l
単純な全体移動だけじゃなくてBPBの書き換えもやってるという理解だったが最近のは違うの？この手のツール。
345:login:Penguin
12/10/11 20:40:39.68 Wk88iD1l
あとこの手の全体移動するツールって移動中に電源落ちても続きから再開できるような対策とか打ってるもんなん？
346:デムパゆんゆんネトウヨ特攻兵＠１０月 読書の秋 【関電 64.6 %】
12/10/11 22:40:43.93 QNMVCMvf
続きはCMの後
347:login:Penguin
12/10/12 10:25:11.66 GbJnfzSW
>>345
中断しても整合性をキープするのが理想だと思う。
転送前後が重なってるなら、一時的に双方を含むパーティションに拡大して、
デフラグ類似の処理をしながら転送前だけの範囲から追い出して、
その後に転送後の範囲に縮小。
てな面倒な処理をしてくれるといいんだけれど。
348:login:Penguin
12/10/12 10:26:46.27 HHTpRhDv
理想語ってる暇あったら自分で実装すべし
349:login:Penguin
12/10/17 14:17:43.56 vrMwbUL5
他スレでこんなこと言ってる人がいたが、どうよ？？
------------------------------------------------------------------------
NTFSのセキュリティ設定はデフォルトの状態でよくできている
※デフォルトのUNIXのファイルパーミッションは最低といってもいい
というかそもそも共有という認識がない
それでも問題点にならないには非常に小規模の共有にしか使わないから
UNIXでも同等のことができるという意見もあるが「実運用したことのない奴の戯言」である
NTFSのエラー訂正機能はext3より若干上(ext2よりは良くなった)
（割と馬鹿にされるがCHKDSKは神ツールである)
350:login:Penguin
12/10/17 14:37:51.35 jvY0yRQX
>>349
どうよって言われてもな・・・
Windowsユーザーから見れば、まぁそういう言われ方するよねぇ。
ぐらいかと。
Windowsメインの共有なら明らかにLinux+sambaのが分が悪い（当然だけど）
acl周りもしかり。
サーバーとしてWindows用意出来るなら、わざわざLinux+samba使う必要無いしな。
色々反論したいところも有るだろうが、
この書き方してる奴に反論したところで、
徒労に終わるだけじゃね。
ってのが、感想。
351:login:Penguin
12/10/17 14:42:42.34 DCqsgCSI
まぁ、適材適所。
352:login:Penguin
12/10/17 14:47:01.24 YMHv2yu3
>>350
思考が狭すぎ世間をしらなすぎ、お前の言うそれはインストールされた
台数でいえば極狭い世界の知識だ。
353:login:Penguin
12/10/17 14:47:45.63 DCqsgCSI
>>352
では経験豊富なあなたの意見をどうぞ。
354:login:Penguin
12/10/17 14:52:30.65 9QEPxsDD
やめろや。比較は荒れるだけ。
いちいち釣りに付き合うな。
355:login:Penguin
12/10/17 15:11:25.66 01TKgxYE
デフォルトがどうとかファイルシステムの仕事とは違くね
356:login:Penguin
12/10/17 15:16:30.84 PvZAHEIs
> NTFSのエラー訂正機能
そんなのあるの?
と思って検索したら最近はそういう機能がついた?
URLﾘﾝｸ(cloud.watch.impress.co.jp)
357:login:Penguin
12/10/17 15:50:25.17 jvY0yRQX
>>352
そうカッカするなよ。
Linuxとか分からないWinユーザーなんてそんなもんだって。
言いたい事は分かるが、最後にちゃんと感想書いただろ？
関わるだけ無駄だと。
だから落ち着けって。
358:login:Penguin
12/10/17 19:31:09.12 SWsIj1dy
そういう話ならスレ違いでござるな
359:login:Penguin
12/10/17 19:47:05.38 SC1964Pi
NTFSは不良クラスタが発生すると自壊して被害が拡大するから嫌い
FATの頃は不良クラスタ発生箇所のファイルの問題だけに極限してたのになぁ
360:login:Penguin
12/10/17 20:48:59.24 RbpW1EIX
bad block handlingの無いXFSにも同じこと言えんの
361:login:Penguin
12/10/18 11:55:37.22 QvtQjgLZ
>>359
まだWindows2000が現役だった頃その罠にハマったわw
結局その時の常用はFATにした。
362:login:Penguin
12/10/18 16:35:38.24 LrtYvlyT
早くこんな世界が来るといいな
メモリ技術の革新がコンピュータアーキテクチャの変革も導く
URLﾘﾝｸ(pc.watch.impress.co.jp)
363:login:Penguin
12/10/18 18:02:34.17 nEi/VRh3
いよいよWinFSの時代か！
364:login:Penguin
12/10/18 21:42:23.50 Uwcr8ZaT
Wii のバーチャルコンソールとかのゲーム機エミュレータで遊ぶと、
どこでもセーブがありがたいけれど、
不揮発メモリもそんな感じかな？
365:login:Penguin
12/10/18 23:04:38.08 CZbR+4vN
なんとなくサイバーパンクっぽいけどオブジェクトのリンクをたどるのもi-nodeのリンクをたどるのもあんま変わらん気もする
366:login:Penguin
12/10/18 23:27:58.96 Svf3uX/8
HDDがPCからなくなる事はあってもファイルシステムは残る、
ファイルをメモリに再展開しないで直接参照するようになる、
それは現状でも可能。
PRAMが一番単純だ寿命はMRAM、RAMはMRAMになりFLASHはPRAMになる、
速度が稼げればMMは1GBで十分、MMとPRAM間の転送を100GB/sに高める。
スパコンやクラウドは既にメモリ＋演算機構の分散システムになっていて、
大規模な処理ではICｰNWの速度がその性能を規定している。
367:login:Penguin
12/10/22 16:00:09.50 o36esTpA
>>349
Windowsのファイル共有がクライアントも含めてセキュアになったのなんてここ10年の話じゃないか。
10年前はサーバですら追加パッケージ入れないとITSECの規準も満たさなかったし。
今もProfessionalじゃないと話にならないだろ？
368:login:Penguin
12/10/22 18:41:11.05 N8Jtvfqg
XFSとFTPに出会えた事を誇りに思う
こんな事が言える男が世界にどれだけいるだろう
心から感謝している
369:login:Penguin
12/10/23 02:09:12.40 WU9pwdoJ
>>366
その手の話は楽しそうだけど、スレ違いだから遠慮しておく
370:login:Penguin
12/10/23 06:54:16.77 9JHFz3mT
遠慮せず、スレ移動して続けたら?
371:login:Penguin
12/10/23 12:26:22.73 0oB+osl5
gnomeのごみ箱がntfsに対応していない
372:login:Penguin
12/10/23 18:37:45.79 ZFhcO2Ju
パーティションに書き込み権限が無いだけ
373:login:Penguin
12/10/25 08:43:13.91 zqYpInVT
AppleのFusion Drive
SSDとHDDのいいとこ取りのディスクシステム。
Linuxのファイルシステムでまねっこするには、
FlashCacheが一番近いかな。
374:login:Penguin
12/10/25 16:21:46.50 wiAOfp6Y
Appleの売り文句を真に受けるとバカを見る
375:login:Penguin
12/10/25 16:39:14.43 dcwDITH+
Hot Dataという仕組をVFS上に考案されていてまずbtrfsへの実装が進められている。
376:login:Penguin
12/10/25 16:39:49.21 dcwDITH+
>>375
> Hot Dataという仕組をVFS上に考案されていてまずbtrfsへの実装が進められている。
Hot Data Tracking
377:login:Penguin
12/10/25 23:34:28.46 UqYCZsNh
[Phoronix] EXT4 Data Corruption Bug Hits Stable Linux Kernels
URLﾘﾝｸ(www.phoronix.com)
カーネル3.4以降のExt4でファイル破損の不具合ですか。
それとも3.6.2の話かな。
私は2.6.32だけど心配だからExt3で再インストールしようかな…。
378:login:Penguin
12/10/26 02:57:48.55 Gx6HHt8O
3.6.2で入ってその後3.4にもバックポートで混入
379:login:Penguin
12/10/26 08:39:13.13 gJ8NKbwz
バグの発動条件は短い期間にmount/unmountを繰り返すことみたいだから、
当たることもそうはなさそう。
2.6系だとむしろext4のコードが古すぎて微妙とかないのな。
380:login:Penguin
12/10/26 08:40:26.38 O4FrXTWG
それってautofsとか使ってるとアタる可能性があるってこと？
381:login:Penguin
12/10/26 10:13:36.36 b7aJ0gK4
>>376
なるほど、btrfsの今後の実装を刮目して待て！！
という話ですね。
382:login:Penguin
12/10/26 12:31:52.08 Fqb7Vkhu
抜く前にsyncsyncsyncすれば回避できるかな？
383:login:Penguin
12/10/26 15:42:47.69 pT4dWmUW
>>377
>>379
URLﾘﾝｸ(plus.google.com)
によると
今のところ調査中みたいだけど、かなり限られた状況じゃないと破損は起きないみたい。
umountせずに電源を切る(umount -l後にbusyが解消される前に切るとか)
次回mount時にnobarrierオプション付きでマウント
この二つを満たした時に破損の可能性が出てくるらしい。
とりあえずnobarrierをつけてない人は、まぁ大丈夫でしょ
384:login:Penguin
12/10/27 00:52:26.66 2cXd+0y5
アンマウント完了前に電源が切られることがある…のか。
そういえば以前から気になっていたけど、Linux終了するとき
外付けのUSB-HDDが「カキューン」とか鳴って
いきなり電源切断されたようになる。
(サスペンド中もUSB-HDDのモーターが回っている)
Windowsなら、HDDのモーターが止まってから静かに電源断されるのだけど。。
(サスペンド中はUSB-HDDのモーターが止まっている)
今回の修正でついでにそこまでやってくれないかな…。
385:login:Penguin
12/10/27 02:15:46.98 ZNGg/pVZ
>>383
バグかぉ！？
Xが固まって強制リセット後破損
nobarrierつけてるから破損したんだな仕方ない自業自得か
と思って納得してたんだが…？なんか間違ってる？
386:login:Penguin
12/10/27 17:34:09.20 kLEmFi68
今時のファイルシステムは、不意のシャットダウンでも、破損するんじゃなくて、
新しい書き込みが捨てられるだけであることが期待されてる。
387:login:Penguin
12/10/27 17:44:06.09 AGi5NFZt
それをファイル破損と言うんじゃなくって？
388:login:Penguin
12/10/27 17:48:52.80 kLEmFi68
元記事の英文が読めないんだねえ。
389:login:Penguin
12/10/27 23:19:31.81 GpxaDLzd
>>387
？
390:login:Penguin
12/10/27 23:25:13.01 +7274N+z
書き込みされないのに破損するわけない
391:login:Penguin
12/10/28 00:43:00.91 EGMMc3VL
アプリが書き込んだと思ってるのに、書かれていなかったらファイル破損なんでは？
392:login:Penguin
12/10/28 00:54:10.66 4sjbxmQV
どういうバグなのか理解してから書き込めよ。
「ファイル破損」とかアホかと。
393:login:Penguin
12/10/28 03:02:33.87 qwr6u3Ap
データの損失だな。
フラッシュされてないんだからしょうがない。
394:login:Penguin
12/10/28 03:18:53.76 4iK8nRu6
面倒だからいつも電源ボタン長押しでぶち切ってたから心配だお
まあ破損して困るようなデータじゃないからどうでもいいけど
395:login:Penguin
12/10/28 05:23:47.58 CJGiM68r
ハードディスクの損傷の修復機能はあるだろ？
396:login:Penguin
12/10/28 07:45:58.13 YHACL08l
ハンスごめん
EXT4に浮気した俺が間違ってたよ
397:login:Penguin
12/10/28 11:52:40.99 4sjbxmQV
>>393
はあ？
398:login:Penguin
12/10/29 19:41:09.31 eLEF2BXb
よし、仕事終わったしバックアップ取っておくか
$sudo zfs snspshot rpool/export/home@today
楽チン~
399:login:Penguin
12/10/29 21:08:47.00 3OuSbDia
LinuxのくせにZFSとかずるい
400:login:Penguin
12/10/29 21:28:37.16 1Bghux58
思うにXFSとは、もともとあるものとも言えぬし、ないものとも言えない。
それは地上の道のようなものである。
もともと地上には道はない。
歩く人が多くなれば、それが道になるのだ
401:login:Penguin
12/10/29 23:43:50.62 6l5+Yl0S
スナップショットはバックアップじゃねぇしｗ
402:login:Penguin
12/11/01 22:38:04.00 gzHmXVmP
バックアップの意味を広く捉えるか狭く捉えるか
オペチョンで消したファイルを復活できるのだって広い意味ではバックアップに違いない
物理障害に耐えられないだけで
403:login:Penguin
12/11/01 22:55:53.70 InrMq2kC
いやいや、そこは区別しようよ。
バックアップ、スナップショットで意味は明確なんだから。
404:login:Penguin
12/11/01 22:56:24.00 XjtB3TGE
backup の意味は予備とか代役とか非常用とか
405:login:Penguin
12/11/01 23:13:38.79 zilQmaYL
ファイルシステム的には
$ cp hoge.txt hoge.backup
とほぼ同等のことをCOWでやってる訳だしバックアップって言ってもいいんじゃないの
バックアップが同じHDDあっちゃいけない決まりがある訳じゃないし
406:login:Penguin
12/11/01 23:18:20.03 x/7V4pPf
複製しないし
407:login:Penguin
12/11/01 23:23:33.64 InrMq2kC
簡単なんだから使い分けましょう。
ベル研のWORMみたいに、光学ディスクにバックアップしながら、
いつでもアクセス可能なスナップショットを作成するのなら、
区別しがたいわけだけど。
408:login:Penguin
12/11/01 23:31:05.46 ssBg5K4m
呼び方は置いとくとしても、
スナップショットじゃハードウェア障害に無力だよね。
409:login:Penguin
12/11/02 09:27:58.19 rb1niAqP
オリジナルが必須な時点でバックアップじゃ無いじゃん
410:login:Penguin
12/11/02 11:33:42.33 uIcmYoX5
別ディスクへのバックアップだって遠隔地に取ってなけりゃ災害には耐えられない
何に耐えられるかを以ってバックアップかどうかを定めるのはあまり意味が内と思う
コピーやスナップショットやリモートミラーは実現するための技法に過ぎなくて、
非常時に代替として使えるものは何だって広義のバックアップだろうよ
411:login:Penguin
12/11/02 11:46:35.99 jcF3AZ8S
pgr
412:login:Penguin
12/11/02 11:52:21.97 doWgnh0V
>>410
極端な例を挙げても、バカがいっそう引き立つだけだぞ。
413:login:Penguin
12/11/02 11:54:07.86 rb1niAqP
遠隔地でなきゃバックアップも死ぬよっていうのは別次元の話だな
バックアップの本質的な意義は、明らかに一部または全部が欠損したオリジナルの復元だから
スナップショットも条件限定でのバックアップと言えなくもない
ただ、システムの運用管理を行う上で「バックアップとスナップショットは区別されるべき」っていう話だと思うぞ
414:login:Penguin
12/11/02 12:06:26.07 uIcmYoX5
専門バカ的に、バックアップって言葉の意味を限定しすぎてるだけ
その世界では(狭義には)オリジナルと別の実体を要求されることくらいはわかってる
バックアップという目的に対して適切な手段が場合によってスナップショットだったりディスク内コピーだったりディスク外コピーだったりリモートコピーだったりするだけ
415:login:Penguin
12/11/02 12:15:19.34 rb1niAqP
名称や定義は重要だぞ
まあお前さんは今まで痛い目を見たことがないラッキーガイなんだろうよ
416:login:Penguin
12/11/02 12:54:39.09 uIcmYoX5
名称や定義に無頓着なのはそっち
417:login:Penguin
12/11/02 12:58:42.56 doWgnh0V
>>416
いい加減にしろ、ぼけ
418:login:Penguin
12/11/02 13:29:52.86 GQBvMhUy
的外れな『極論』を持ち出した時点でID:uIcmYoX5の負け
419:login:Penguin
12/11/02 13:39:28.50 ZWB+hg7e
ゆワイターはあっち
420:login:Penguin
12/11/02 14:27:16.67 M+3/Tt7Z
同じディスク内のコピーはバックアップではない
その認識が浸透していたならファーストサーバの事件は防げたかもしれない
421:login:Penguin
12/11/02 16:08:02.73 O/ZR7tTp
>>420
認識が足りないのはお前だろ…
ファーストサーバでは別ディスクにまるごとコピー（二重化）も取ってあったんだよ。
ところが馬鹿な社員がそっちにもバグ入りOSアップデートしたせいで
コピー側も見事にぶっ壊した。
ホット側とコールド側双方一緒に環境更新とか無能としか言いようが無い。
422:login:Penguin
12/11/02 16:30:13.28 GQBvMhUy
>>421
認識が足りないのはお前だろ…
ファーストサーバは待機系をバックアップと称していたけど、
待機系はあくまで本番系に対する（機能としての）バックアップであって、
データとしての『バックアップ』ではない。
そこがごっちゃになってるから話がおかしくなるんだよ。
データとしてのバックアップじゃないんだから、本番系・待機系ともにパッチ当てるのは当たり前。
じゃなきゃいざって時に待機系が使いものにならず、待機系の意味がない。
423:login:Penguin
12/11/02 16:45:48.44 jcF3AZ8S
バカな運用者というのはbyzantine failuresの典型例ですね。
424:login:Penguin
12/11/02 17:41:18.21 RxNdjvVD
この流れ、同じようにバックアップやRAIDについて得意げに解説してくれていたシステム構築発注先のSEが
数日後ノートPCが壊れたとかで、
これまでのメールや資料を再送してくれと泣き疲れた思い出が呼び覚まされた。
425:login:Penguin
12/11/02 17:45:48.11 cPFlJ0Jm
>>410
ポケコンに打ち込んだベーシックのプログラムを、
紙に写経してバックアップしたのを思い出すわｗ
426:login:Penguin
12/11/02 18:41:50.82 6OZ7uj4a
紙にメモするのも立派なバックアップの手段
427:login:Penguin
12/11/02 19:08:12.68 aQt6ihWu
紙にバックアップは最終手段だね。
少なくともPCで取り扱うよりも並べ替えも移動も検索も難しくなるし、
機密情報だったら暗号化もできない。
428:login:Penguin
12/11/02 19:15:38.10 cPFlJ0Jm
しかもだいたい書き間違うしなｗ
まあそこは、復元するとき柔軟に読み込むから相殺されるけど。
429:login:Penguin
12/11/02 19:21:33.39 GPiMhI3k
ふっかつのじゅもんか
430:login:Penguin
12/11/02 22:04:39.91 QbgCEqw1
最近物忘れが多いからメモするようにしたんだが
自分でも読めないくらい字が下手で困る
431:login:Penguin
12/11/03 00:44:45.77 GUd3rUXm
Ext4のバグがまだあるという…
[Phoronix] There Might Be Another EXT4 Corruption Bug
URLﾘﾝｸ(www.phoronix.com)
要は64bitのUbuntuにおいて、12.04で作ったExt4に12.10を入れて
12.10のfsckをすると、ファイルシステムが100%クラッシュする
ということかな。
432:login:Penguin
12/11/03 01:53:20.00 OhvRX3Pe
暗号化とエラー訂正コードを付けてからメモすれば
433:login:Penguin
12/11/03 02:05:55.89 Ez1EqqwX
>>431
ext4がまだ枯れていないという事だろう
安定するためにはもっと人柱が必要なんだ
434:login:Penguin
12/11/03 02:38:00.48 GUd3rUXm
カーネルが
・Ubuntu 12.04 ～ ver 3.2
・Ubuntu 12.10 ～ ver 3.5
なので、似たような状況でも問題が発生するかも知れませんね。
435:login:Penguin
12/11/03 08:50:10.05 x4u+yq7+
まあでも新しいファイルシステムなんてそんなもんだよな。
ZFSも結構問題起きるみたいだし。
436:login:Penguin
12/11/03 09:20:19.76 F3mzMXS2
ext4が枯れていないのにext4でfixされたバグがext3にバックポートされていないものがあるという
437:login:Penguin
12/11/03 09:22:02.50 GUd3rUXm
DebianがExt4を採用しているから大丈夫だと思ったんですが。。
でも今回のはカーネル3.5、先日のは3.4～3.6。
Debian(wheezy)は3.2だから大丈夫かな。
438:login:Penguin
12/11/04 08:33:32.52 DxPDnXqB
XFSはいいものだよ
多分最高のものだ
いいものは決して滅びない
439:login:Penguin
12/11/04 11:55:42.62 DRJDnh5/
btrfsに駆逐されろ
440:login:Penguin
12/11/06 03:57:02.55 pISgWimS
>>438
いいものではなく、商業的に成功したものだけが生き残る
441:login:Penguin
12/11/07 11:08:25.38 rn8yLjcX
Suse Enterprise Server Lnux 11を使ったサーバ構築の案件があって、
試しに仮想PCにインストールしてるんだが、ファイルシステムの
選択にbtrfsが出て来てビックリした。 選ぶと、/パーティションには
使えないらしくインストーラで先に進めないが、データ
パーティションには使えるみたい。
442:login:Penguin
12/11/07 16:34:18.60 WkY+xawT
grub2ではgrub.cfgでinsmod nilfs2を指定できるようになったので、
nilfs2を普通にrootで使えるようになった。
それにしてもnilfs2のファイル削除の遅さは気になるな。
443:login:Penguin
12/11/07 16:50:54.73 s8f4SsG0
全く関係無いんだけど誰も話す相手がいないから書かせてくれ
随分前から海面上昇が問題になってるけどさ
あれって世界中が貿易が盛んになって
でっかいコンテナ船やらタンカーをたくさん浮かべたからだと思う
北極の氷が溶けたのが原因って言われてるけど
氷って元々ほとんど水の中だし溶けたら逆に体積減るからあんま関係ないと思うんだよね
どうだろ？
ちなみに俺はXFSが好き
444:login:Penguin
12/11/07 16:53:26.38 4OoAyn3a
長いファイル名サポートはよお願い
445:login:Penguin
12/11/07 16:55:02.28 FcTcq6ln
>>443
ひとり言はこっちで。
URLﾘﾝｸ(kohada.2ch.net)
446:login:Penguin
12/11/07 20:31:58.27 JJe03jty
海面上昇とXFSに何の関係が？
447:login:Penguin
12/11/07 22:24:16.18 mdV+jyok
データセンターは山の上に作れってことさ
448:login:Penguin
12/11/07 22:47:44.71 lMZK0FqX
データセンター立てるなら滋賀がいいですよ～
環境いいし交通の便いいし海抜80m以上あるから海面上昇とは無縁だし
449:login:Penguin
12/11/08 02:16:29.58 7q9PSQRu
寒くないと空冷できないべ
雪でも降れば貯めておいて使えるが
450:login:Penguin
12/11/08 02:33:19.97 /O1n10+6
滋賀は結構雪降るよ
451:login:Penguin
12/11/08 03:51:16.16 +t0fE3Pf
滋賀って例の大津市ある所じゃないか……。
452:login:Penguin
12/11/08 08:06:26.32 ulF68DIF
何のスレだよ。
453:login:Penguin
12/11/08 09:34:55.84 uMkvhnVA
データをイジメ殺すからやめてください！
454:login:Penguin
12/11/08 11:45:53.05 HTy/v2GZ
いじめの名所滋賀県
455:クラウドはドリームソルジャー？
12/11/08 12:18:43.74 +L/AjMM3
雲散霧消に定評のあるファーストサーバー。
多くのデータが消えていった。
456:login:Penguin
12/11/08 13:43:40.71 FNcrRuT7
常時snapshotのNILFSなら無事だったのにね
457:login:Penguin
12/11/09 00:14:21.82 qlO8XAcr
32bitカーネルと64bitカーネルでファイルシステムの違いが生じるってこと
ありますか？
458:login:Penguin
12/11/09 11:12:38.73 lm7rqEO+
開発者も64ビットと32ビットの両方の環境で動作するのが面倒らしく、
64ビットなら動くけど、32ビットでは動かなかったという事例は
ありそう。ファイルシステムでは無いが、別のシステムで経験があるよ。
開発者にメールしたら「え、32ビットまだ使ってるの？」って。
真面目なヤツで、次の日には改修済みの32ビット版のオプジェクトを
作ってくれたっけ。
459:login:Penguin
12/11/09 12:03:21.07 S4+d2JBp
ま、Linuxであえて32bit使っているのはUbuntuの馬鹿どもぐらい、
というイメージだな。
460:login:Penguin
12/11/09 12:26:52.89 tly6/47p
Droid君がアップを始めたようだ
461:login:Penguin
12/11/09 14:46:00.73 EhvrUbww
>>459
お前も馬鹿だろ。
まだまだ非64bit環境でLinux使ってるの多いんだよ。
462:login:Penguin
12/11/09 14:53:12.28 Gjeu7Hay
>>459
おまえのイメージはPCの話だろ
linuxは組み込み用との方が圧倒的に多いだろ
463:login:Penguin
12/11/09 15:37:42.41 TSMauyzz
>>462
でも組込みも64bit化してかないとヤバイ
2038年問題がヤバイ
464:login:Penguin
12/11/09 15:43:06.11 nMUC+MIA
アホかと。
カーネルの64bit化と2038年問題は関係ない。
time_tはカーネルの64bit化とは関係なく、既に64bit化されてる。
古いファイルシステムの内部データに32bit time_tが残っているのは大問題だが、
カーネルを64bit化すれば直るわけではない。
465:login:Penguin
12/11/09 16:01:17.49 NCnS2ylI
もったいないのが
64bit対応CPUで32bit使うこと
Ubuntuは未だに32bitがrecommendedだし
あと広く普及しているcore2duoは64bit対応だけど32bit全盛期に発売されたから未だ多く32bitCPUとして使われている
64bitにしたら有効メモリーはもちろん処理が速くなる
メモリー4GBも使わないからいいやとかPAEでいいやとか思わずCPUが対応してるならどんどん64bitにすべき
466:login:Penguin
12/11/09 17:38:26.30 J6obOOP6
適材適所がわからないバカはどうしようもないな
467:login:Penguin
12/11/09 18:19:26.77 tb9hKVQD
拙者32bitのUbuntuを使っている馬鹿でござる
468:login:Penguin
12/11/09 18:41:17.89 PEnheJzq
左様でございますか
469:login:Penguin
12/11/09 18:51:15.82 TsbbGiwx
ユーザーランド64ビットでもまあ構わないんだけどポインタは4バイトでじゅうぶん。どうコンパイルしたらいい？
470:login:Penguin
12/11/09 18:56:19.18 nMUC+MIA
自分でコンパイルしたコンパイラとライブラリを使ってください。
システムコールはポインタ渡しの部分が32bit版と64bit版と二種類用意されているので、
適切な方を呼び出すようにしてください。
後はELやld.soF内に閉じた話なので好きにやってください。
471:login:Penguin
12/11/09 18:57:21.62 J6obOOP6
使用目的に合わせて機器・使い方を選ぶのが適材適所であって
64bit対応ハードウェアなら何が何でも64bitで使うべきとほざくのがバカ
472:login:Penguin
12/11/09 19:08:08.64 NCnS2ylI
>>471
だってせっかくのCPUの性能をフルに発揮したいじゃん
「処理速度が向上する」を不必要と思う人はいないじゃん
473:login:Penguin
12/11/09 19:15:50.18 pbnT+2De
リスト構造をダンプして上位4バイトほとんど同じのみたらメモリーもったいないんだの。
IL64もしくはL64モデルでいい。
474:login:Penguin
12/11/09 19:17:07.84 pbl6itVC
>>472
キャッシュにおさらまらなくなると遅くなるよ。
475:login:Penguin
12/11/09 19:51:15.22 H1ZvvXvX
64bitにしたって、普通の用途では速度向上はほぼ実感できないだろ。
むしろメモリフットプリントが単純に増えるから、メモリが4GB以下なら64bitにするメリットがほとんどない。
476:login:Penguin
12/11/09 20:00:59.27 9NSaHAI2
x32ABIでいいじゃん
つか、FS関係無いだろ
477:login:Penguin
12/11/09 20:11:59.07 7LQKEDvt
x86にたいするx64なら64bitという点ではなくISAの拡張による利点がある
汎用レジスタが増えたり命令相対アドレッシングが可能になったり
478:login:Penguin
12/11/09 20:14:46.74 3ru+Kify
AMD64はレジスタ周りの設計改善で、64bitで使った方が速いらしい。
479:login:Penguin
12/11/09 20:39:17.08 HjNXfa0O
精度がfloatでじゅうぶんならdoubleより速いのにdoubleの固定観念を捨てられないおじさんみたい。
480:login:Penguin
12/11/09 22:00:33.07 VDgsiS8o
ubuntu64bitだとfluxbox環境でmltermのアイコンがなぜか化けまくる
481:login:Penguin
12/11/09 22:39:07.44 nMUC+MIA
/usr/share/pixmaps/mlterm*を全部表示してみてください。
というかスレ違い。
482:login:Penguin
12/11/10 03:08:21.46 skqN2pV+
>>479
x86のFPUは倍精度で動いとるからdoubleの方が余計な変換処理入らない分速い
てファイルシステムとどう関係あるんだ？
483:login:Penguin
12/11/10 03:42:22.35 BtRf1foD
>>482
別にかわらんのじゃないのか。
変換処理なら内部80bitだからdoubleでも入るぞ。
484:login:Penguin
12/11/10 06:07:04.85 CGoNRL+B
SSE
485:login:Penguin
12/11/10 08:08:42.58 yA/REe8u
>>464
sys_timeシステムコールを見るとtime_t返してるし、libcと同じくカーネル内でもlongで定義されてませんか？
486:login:Penguin
12/11/10 08:51:07.94 xknH4hBW
>>481
32bitと64bitで差がなかったyo
487:login:Penguin
12/11/10 09:33:08.87 J4Ln9o96
80bitって今日日x87コードなんか誰も書かないと思うけど
現状x87はコードは推奨されてないしコンパイラーもんなコード吐かない
488:login:Penguin
12/11/10 12:32:14.43 VbwvG4Uy
>>482
コントロールレジスタを_FPU_DOUBLEに設定していようが変換入るんだがね
489:login:Penguin
12/11/10 16:14:21.76 DAGxbFTw
ext4 の defrag まだかな。
490:login:Penguin
12/11/10 16:47:14.79 PrjxxuV6
e4defragとかfake_defragとか？
491:login:Penguin
12/11/10 17:08:37.17 Swni5aMO
linuxのデフラグはコピーして戻すのが王道だろw
492:login:Penguin
12/11/11 01:22:09.46 troQki0D
>>489
なんでデフラグしたいの?
493:login:Penguin
12/11/11 06:58:19.57 2Eng4Y+V
昔「デフラグする奴は貧乏人」ってスレがあったな
494:login:Penguin
12/11/11 10:40:48.36 osAwJNEG
デフラグする奴はアホ
初期化する奴のほうが情強
495:login:Penguin
12/11/11 10:46:04.14 bP6rS7i3
本当の情強はLinuxなど使わない
496:login:Penguin
12/11/11 10:48:05.27 QIAgZ7z2
freeBSDでZFSを使う
497:login:Penguin
12/11/11 11:07:33.39 3kaPvPl7
SolarisやHaikuもいいな
498:login:Penguin
12/11/11 16:23:07.56 0JBWKQCc
そもそもLinuxが沢山のファイルシステムをサポートしてるのはなぜ？
初期にメインファイルシステムをどれにするかで、迷走したとか？
499:login:Penguin
12/11/11 17:08:34.59 qt5OlzxZ
>>498
最初はExt系だけで、Linux気質の「来る者拒まず、去る者追わず」でどんどん増えた様な。。。
500:login:Penguin
12/11/11 17:30:17.28 e/1Iatys
ext2の実装がひどかったのも、いろいろ作りたい人が出てきた理由だと思う。
ただ最近はきっちりと役割分担が出来ているので、もっとあっても問題ない。
501:login:Penguin
12/11/11 17:43:17.09 hvw58Qyv
煽り要素ゼロで言うんだが、「ext2の実装がひどかった」てすごいな…。
ファイルシステムの実装について評価できるやつがこのスレにはいるのか。
502:login:Penguin
12/11/11 17:57:57.77 mNzMe6Pv
十人いれば十人十色の需要があり、それに応えた/自分で開発した
ってだけでしょ。仕様公開してないNTFSのサポートだけが不完全ってだけで。
503:login:Penguin
12/11/11 19:11:03.72 2c3JORIq
>>501
ジャーナルが無かったので、システムがフリーズしたり、
停電の後、再起動が出来るか不安なファイルシステムだったよ。
504:login:Penguin
12/11/11 19:12:56.91 hvw58Qyv
不安定さはそうだろうけど、
ジャーナリングの有無なんてもんは単に仕様の話じゃね？
505:login:Penguin
12/11/11 19:14:06.30 as9ZdwRQ
そのジャーナルのお陰でext3は遅いけどな
506:login:Penguin
12/11/11 19:15:21.29 OLX557RM
それはext2の実装じゃなくて設計の話じゃないのか
507:login:Penguin
12/11/11 20:09:20.02 MEPnKq2m
minixのfsがウンコだったから作ったんじゃなかったっけ？
508:login:Penguin
12/11/11 21:33:15.34 qDC9w+h9
フリーズしたらマジックキー
停電はUPS使うだろ普通
509:login:Penguin
12/11/11 21:36:06.58 QIAgZ7z2
>>508
マジックキーって効かないこともあるんですけど
UPSなんて一般家庭にないんですけど
510:login:Penguin
12/11/11 22:19:40.90 as9ZdwRQ
一般家庭で使う事が限定の話だったの？
511:login:Penguin
12/11/11 22:22:41.98 3kaPvPl7
一般家庭でなくなったら困るデータとかないし
512:login:Penguin
12/11/11 22:27:00.81 QIAgZ7z2
だってLinuxはデータセンター専用OSじゃないもん
データセンターやUPSがある自宅鯖宅でも使われるけど
組み込みやUPSなし自宅サーバー
そして大きいのはデスクトップPC
としても使われる
一般家庭や企業のデスクトップPCにUPSなんてつけませんよ
513:login:Penguin
12/11/11 22:28:48.70 QIAgZ7z2
>>511
あるし
家族の写真とか
仕事の書類とか
コードとか
ムフフ動画とか
etc
514:login:Penguin
12/11/11 22:36:14.35 hvw58Qyv
UPSのバッテリが切れて、UPS機能失って単に電源タップとして使って早数年。
劣化したバッテリが溶け出してないか確認するのが怖い。
515:login:Penguin
12/11/11 22:38:21.86 KOknrrgB
家は貧弱だったのでリホームするまでUPS必須でした。
エアコンのサーモスタットがONするとPCがリブートするんだよなあ...
516:login:Penguin
12/11/11 22:51:23.87 OI+msgGo
UPSも冗長化しよう
517:login:Penguin
12/11/12 01:53:04.86 usLhJzvA
電力自由化がほんとに実現しちゃったら家庭でもUPSあった方が良くなるかもね
518:login:Penguin
12/11/12 01:53:10.22 p4TTgDL2
>>500
初代extがクソだったのでext2で再実装されたという話と混ざってないか？
519:login:Penguin
12/11/12 02:01:17.16 Mu3t822q
多様性だろ～
520:login:Penguin
12/11/12 02:13:13.49 06Vk+cuQ BE:512125632-2BP(1001)
ext2の時代は対抗馬のfatが恐ろしくクソだったけど
ntfs知ってしまうとアレだよな。ext4もbtrfsも中途半端って幹事
521:編集中のは失われて当然
12/11/12 02:59:34.62 UGWhY7R0
ntfsで動いているPCの電源コードを抜くのとext4で動いているPCの電源を
抜きそのまま再度何もせずに立ち上げたときどっちが何もしなくていいかで
評価するべきだよ。
ジャーナルファイルシステムとか言う以前にOSを含めた結果という事実が
重要になる。何もしなくて良いというなら1万回やって1万回同じ結果が
でるかを確認しろ！
#UPSとかsyncしないやつ&処理手順の言い訳。
522:login:Penguin
12/11/12 08:38:21.37 W2Pfq0dm
リブート時はsyncを3回ですね判ります
523:login:Penguin
12/11/12 08:53:45.05 CX737Rul
昔々、シングルユーザモードでSyncコマンドを実行すると、管理ブロックが
吹き飛んでしまうSUNのSoftware RAIDがあってね。（遠い目）
復旧は出来たけど、徹夜したっけな。
524:login:Penguin
12/11/12 17:37:15.29 8Qp/kenG
人生からXFSを除かば、世界から太陽を除くにひとし。
525:login:Penguin
12/11/12 23:26:50.03 xQbnJAl3
ext3,4の利点は再起動時のfsckが速いだけ。それ以外は全てにおいてext2の方が速い。
526:login:Penguin
12/11/12 23:40:27.82 WaGtjXoi
>>525
ジャーナル切ったベンチマークでext2よりext3が速くなかったっけ
527:login:Penguin
12/11/12 23:51:01.66 MTTZ8jKH
そういえばXFSもLinux由来では無いんだよな
SGI IRIXのをパクってきたんだっけか
528:login:Penguin
12/11/12 23:58:08.07 WaGtjXoi
>>527
SGIが移植したんだからパクりとは違う。
529:login:Penguin
12/11/13 01:13:48.21 b+E15Mqx
reiserfsとか
530:login:Penguin
12/11/13 03:38:06.23 D/TVeJeO
>>527
JFSもIBMがAIXのために開発したのがベースだよな。
531:login:Penguin
12/11/13 13:24:41.71 4hnSewz5
>>526
ext3にはジャーナル切れるモード無いだろ
532:login:Penguin
12/11/13 20:24:20.05 W3Xvs8tT
JFSとかXFSとかZFSとか、名前の付け方に芸が無さ過ぎ。
やっぱりvfatがクールだね
533:login:Penguin
12/11/13 20:30:49.76 Li2kj3Ue
日本初のファイルシステムがもしできたら
YAKITORI とか FUJISAN とかそういう命名しちゃうんだろうな。
534:login:Penguin
12/11/13 20:33:17.46 Li2kj3Ue
NILFSのこと忘れてたorz
535:login:Penguin
12/11/13 22:12:00.26 c6Gv8FFi
>>533
KOMADORIとかDOZEUとかの方がいいよね
536:login:Penguin
12/11/14 08:36:45.12 pwsZZAJP
aufsも日本人作だけど、普通のファイルシステムとは趣きが違うかな。
537:login:Penguin
12/11/14 20:24:11.63 UGegE3lQ
aufsは早くカーネルとマージして欲しい。
538:login:Penguin
12/11/15 05:19:36.12 Mm3MRx8E
URLﾘﾝｸ(gizmodo.com)
某ファイルシステム作った奴も殺人で転落したが、
セキュリティソフト作った奴も殺しで指名手配される時代になりました
539:login:Penguin
12/11/15 06:40:04.05 ug6bbry/
社名とか製品名に人名が使われてるとこういうときに怖いよなあ
540:login:Penguin
12/11/15 07:34:03.76 FjYmvev5
だから空母みたく全部エンタープライズみたいににしときゃよかったのに
541:login:Penguin
12/11/15 16:12:59.54 6jjEVyY7
そうなるとLinuxはこのままの名前だと大きなリスクを抱え込んでることになるのか。
542:login:Penguin
12/11/15 19:12:33.20 qQS2lqjV
Debianは黒歴史
543:login:Penguin
12/11/15 20:10:39.57 d0iNsTKG
Tomoyo Linuxとかな
544:login:Penguin
12/11/16 08:13:24.01 3ebm/7xg
人殺しのRiserは普通に使われてんの？
545:login:Penguin
12/11/16 22:08:16.24 OpER4CVb
普通に xfs も reiserfs も使ってるよ。
あと xfs 誉め殺ししてるヤツがキモい。
以前執拗に叩いてたのと同一人物だろ。
546:login:Penguin
12/11/16 22:11:10.14 KdowCz7z
>>545
みんなわかってるよ。
だから無視している。
547:login:Penguin
12/11/16 23:08:00.73 8YtSUCDX
最も軽くて速いのはreiserfs
548:login:Penguin
12/11/16 23:32:24.36 uLV1S0fd
うちのサーバでいちばん使ってるfsはcgroupだわ
# mount | awk '{print $5}' | sort | uniq -c
1 autofs
5 btrfs
9 cgroup
1 cifs
1 configfs
1 debugfs
1 devpts
1 devtmpfs
1 ext4
1 hugetlbfs
1 mqueue
1 nfsd
1 proc
1 rpc_pipefs
1 securityfs
1 sysfs
4 tmpfs
549:login:Penguin
12/11/16 23:51:04.33 xJSveBfa
ext4でなくbtrfs 使うメリットって何？
やっぱスナップショット？
550:login:Penguin
12/11/17 01:27:58.55 1BNr4K4i
ramfs最強
551:login:Penguin
12/11/17 01:46:01.81 hmwTkRqk
>>549
subvolumeが作れるとかsoftware RAIDがあるとか
552:login:Penguin
12/11/17 02:24:53.10 TonMVE3C
>>549
ラリー・エリソンにケツの穴までどころか身も心捧げられる
553:login:Penguin
12/11/17 02:48:32.34 ogziJxY2
ZFSっていつ主流になんお
554:login:Penguin
12/11/17 04:43:51.81 Q1mEG0vK
>>548
なんでバラバラで使うの？
555:login:Penguin
12/11/17 10:08:19.13 r562EpQO
>>548
何で29もマウントされてるの？
普通10もないでしょ
556:login:Penguin
12/11/17 10:17:15.99 hmwTkRqk
>>552
メインの開発者がもう逃亡してるから滑ってるよ
557:login:Penguin
12/11/17 10:25:41.27 yRzEMjtW
>>555
俺は26個だった
最近はcgroup関係とかusbfsとかそういうファイルシシステムじゃない
カーネルモジュールによってmountされてるものが多いな
558:login:Penguin
12/11/18 03:23:37.01 dP2pFDuU
>>557
フォーマット（区画がない）しないのにmountされることはないだろ。
カーネルに実装されていればmountされているというなら誰でもmountされて
いるというべき。
559:login:Penguin
12/11/18 06:36:03.12 J7i7lOLm
犬がマウントしてる
560:login:Penguin
12/11/18 09:58:36.51 SxCqCLu6
>>558
devfs
561:login:Penguin
12/11/18 19:19:00.32 3AJJp3i4
>>558
意味不明
nfsは？
562:login:Penguin
12/11/19 00:57:31.19 j1bL7btg
mountされている一覧にでてこないものをmountというのって頭変じゃね？
最低でもマウントポイントのディレクトリ作ってから家よ。
563:login:Penguin
12/11/19 17:01:23.90 DXm20sJ0
>>530
しかしLinuxのJFSはOS/2実装がベースなのだった。
最初のうちは「大文字小文字の区別ができない」とかそんな制限があったような。
564:login:Penguin
12/11/19 20:12:57.87 9Na0NKql
>>562
mount(2)システムコールを呼ぶ際に/etc/mtabに書き込むかどうかは
アプリに依るんだしそれは言い過ぎじゃね?
565:login:Penguin
12/11/19 20:35:23.74 AdHcY/+d
ここはmountについて語るスレではなくファイルシステムについて語るスレだ。
local,network,pseudoとくに限定してなさそう
566:login:Penguin
12/11/20 05:45:15.78 5COMWB25
[Phoronix] Linux 3.7 File-System Benchmarks: EXT4, Btrfs, XFS
URLﾘﾝｸ(www.phoronix.com)
567:login:Penguin
12/11/20 15:18:59.96 QR6MQbLl
>>530>>563
いやもともとOS/2でdevelopされて、その後LinuxとAIX。
OS/2以外ではcase insensitiveはoption。
568:login:Penguin
12/11/20 15:32:33.29 fiRGral6
JFSならAIXがオリジナルだろう
HPFSならOS/2だが
569:login:Penguin
12/11/20 16:28:21.32 QR6MQbLl
JFS1がAIX上。1990
大幅に改定されたのがOS/2上。これがLinuxとAIXに移植。1999
移植と並行してAIXが主開発場になって、1997
JFS2へ。2001
570:login:Penguin
12/11/22 21:08:48.48 aGVqJPfv
ZFSで冗長性なしでストレージプールを作成した場合
HDDが一台でも物理故障したらプール全体が死ぬという理解であってますか？
571:login:Penguin
12/11/22 22:08:52.69 V6Q46nve
>>570
合ってます。
一ファイルが複数台に分割されて書き込まれるので…
572:login:Penguin
12/11/23 12:39:37.99 DgCxL4o6
2040年問題 - HFSのタイムスタンプは2040年2月6日までしか取り扱えない。
2048年問題 - 2038年問題の1980年起点版。FATファイルシステムのタイムスタンプなどが1980年起点である。
2079年問題 - FATファイルシステムのタイムスタンプの起点の1980年1月1日を基点として、年数を下2桁だけで処理するソフトウェアなどは、その起点の99年後（2079年12月31日）までしか正常動作しない。
2108年問題 - FATファイルシステムのタイムスタンプは2107年12月31日までしか取り扱えない。
-----------------------------------------------------------------------
60056年問題 - NTFSのタイムスタンプは60056年5月28日までしか取り扱えない。
NTFSはいいとしてFATとかどうすんお
573:login:Penguin
12/11/23 12:56:19.65 pQi12ICh
FATの2048年とか2079年問題はファイルシステムの問題じゃないよね。
2108年問題はファイルシステムの問題かもしれないけど、あと90年もFATが現役かなあ？
2040年のHFSの問題はファイルシステムの問題かもしれんけど、古いMacなんか趣味でしか使われてないから問題なさそう。
574:login:Penguin
12/11/23 13:53:01.92 1DjkZ8PV
OSやAPがFSのタイムスタンプを符号あり扱いするように仕様変えれば
FSのブロックレイアウトは変わらないから68年先伸ばしできるお？
作りかえれないOSやAPはコードよりデータの寿命を優先してそれまでに捨てる
575:login:Penguin
12/11/23 17:45:22.26 zzuUWSlp
そんなのもはやFATとよべない。
おれの誕生日に作ったファイルかはるか未来のファイルに化ける。
576:login:Penguin
12/11/23 18:21:41.90 B796Zs33
2048年問題って聞いたことない
FATの精度が2秒だからそんなのないんじゃないの？
577:login:Penguin
12/11/23 21:06:42.92 unSoxewK
>>576
FATディスクフォーマットのタイムスタンプが累計秒数で記録されていると思ってないか
578:login:Penguin
12/11/23 23:43:26.49 B796Zs33
URLﾘﾝｸ(free.pjc.co.jp)
FATは年(7)/月(4)/日(5) 時(5):分(6):秒(5)と
カッコの数だけビットを割り当てて管理してるので
2048年に何か問題が起こるとは思えない
7bit確保されてるので1980+127=2107年まで大丈夫
でもDOSが内部的にどう時間を管理してるのかよく知らない
2048年に何か起こるんですか？
579:login:Penguin
12/11/24 00:31:42.14 PEn0woT6
>>578
ファイルシステム上は問題は起きないが、ファイルのタイムスタンプを1980年1月1日深夜0時ジャストからの経過秒数として32bit整数で保持しているプログラムが正常に動作しなくなる。
……ただし、そんなプログラムが実在するかは知らない。
580:login:Penguin
12/11/24 00:53:51.90 tmvWLVRx
DOSの時間系関数を使って管理してるDOSアプリには2048年問題は起こらない
ダメなのはC標準関数使ってるDOSアプリということですね
UNIXからFATをフォーマットしてる場合は48年以前に38年問題にひっかかるわけですし
581:login:Penguin
12/11/24 00:57:26.99 tmvWLVRx
×フォーマット
○マウント
582:login:Penguin
12/11/24 01:12:53.22 tmvWLVRx
いや、やっぱりC標準関数は1970年を基点とするからそれはないだろうな
FATで0x0000 0x0000というタイムスタンプのファイルがあったとして
それはエポック秒で315500400と変換されてしまうから48年問題は起こりそうにない
アプリで独自に符号付32bit値として保有してる場合だけに48年問題は起こる
こんなアプリ作ってる人いるんかいな？
583:login:Penguin
12/11/24 01:35:11.25 Khi9rNEZ
Linuxのmanpage見たら、ファイルの状態を取得する stat(), fstat(), lstat() 関数は、
ファイルの日時に time_t を使っていますね。
time()関数 ～ 紀元 (1970年1月1日00:00:00 UTC) からの経過時間を秒単位で返す。
も、返すのは time_t。
time_t をたどると正体は
/usr/include/bits/types.h:103:#define __SLONGWORD_TYPElong int
で 32bitのようですが、time_t を使うもの全般が、ファイルシステムに関係なくまずいのかな。
584:login:Penguin
12/11/24 01:39:16.07 Khi9rNEZ
>>583
くっついてるw
× > /usr/include/bits/types.h:103:#define __SLONGWORD_TYPElong int
○ > /usr/include/bits/types.h:103:#define __SLONGWORD_TYPE long int
585:login:Penguin
12/11/24 01:52:10.32 ynQbzFjy
time_tの正体が何かはシステムによって違うでしょ。
586:login:Penguin
12/11/26 11:57:20.62 5um68ud/
>>464
＞time_tはカーネルの64bit化とは関係なく、既に64bit化されてる。
まじで？
time_tが64bit化されたlibcのバージョン教えてくださいおねがいします
587:login:Penguin
12/11/26 17:41:47.54 fgUG4e/Q
GNU libcではtime_tはlong intであってlong intの大きさは処理系定義なので
まあきっとあってもおかしくはないとかなんとかかんとか
588:login:Penguin
12/11/26 17:55:27.87 kLZfMEml
32ビットでフォーマットされているものを突然64ビットで扱おうとして
データを壊しまくるファイルシステムｗ
589:login:Penguin
12/11/26 21:05:38.16 AuvtZE0G
>>586
＞>>464
＞＞time_tはカーネルの64bit化とは関係なく、既に64bit化されてる。
ubuntu 12 i386でsizeof time_tをprintしてけど32bitだ
590:login:Penguin
12/11/27 03:27:25.68 Z/NY1RrE
Ubuntuは32bitということですが
64bitに対応したLinuxディストリビューションはどれになりますか？
591:login:Penguin
12/11/27 04:23:12.75 Z/NY1RrE
あと初歩的な質問になりますが
32bitのLinuxからも、64bitのLinuxからも、
同一のファイルシステムをmountして問題なく扱えますよね？
例えば、ファイルのタイムスタンプの扱いが気になるのですが、
そこは、どちらにしてもファイルシステムの仕様通りに
きちんと処理してくれているということでしょうか。
592:login:Penguin
12/11/27 20:37:59.37 4DO8DdDv
Ubuntuにも64bitなかったっけ
マウントの問題は大丈夫
593:login:Penguin
12/11/27 21:02:09.58 yZTntV89
__STD_TYPE __TIME_T_TYPE __time_t; /* Seconds since the Epoch. */
594:login:Penguin
12/11/27 21:11:04.70 Z/NY1RrE
>>592
Ubuntuに64bitありますね
ありがとうございます
595:login:Penguin
12/11/27 21:17:04.40 eYUehpwt
#include <time.h>
#include <stdio.h>
int main(void)
{
printf("%d\n", sizeof(time_t));
}
8だった@Debian sid/amd64
596:login:Penguin
12/11/27 21:32:19.31 +FTMVYlJ
ちょww8ビットてww
597:login:Penguin
12/11/27 21:34:21.94 yZTntV89
8bytes
598:login:Penguin
12/11/27 22:03:33.10 2Faa51y/
>>595のやつ
Debian6.0.6@amd64(サーバー)
Ubuntu12.10@amd64(デスクトップ)
どっちも8でした