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でした
599:login:Penguin
12/11/27 23:05:11.14 P3Z6acGK
>>591
x86とAMD64で何が違うのかをもうちょっと知れば、そういう質問は出てこない気がするなあ。
600:login:Penguin
12/11/27 23:56:12.21 huHpR5/K
Linux vmware-virtual-machine 3.2.0-33-generic #52-Ubuntu SMP Thu Oct 18 16:19:45 UTC 2012 i686 i686 i386 GNU/Linux
Linux version 3.1.10-g22b4fcd (android-build@vpbs1.mtv.corp.google.com) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #1 SMP PREEMPT Fri Nov 2 10:55:26 PDT 2012
てもとだとこの2つはsizeof(time_t)は4だったが
>>464の
「time_tはカーネルの64bit化とは関係なく、既に64bit化されてる。 」
と矛盾してないのか？
601:login:Penguin
12/11/27 23:57:18.46 +wYW/dtS
>>599
32bitと64bitとしか書いてないからx86とamd64とは限らない。
というかその二つに限定すると理解が疑われかねんな。
602:595
12/11/28 02:17:16.58 nx7Okma8
なんとなく気になったので同じ環境で-m32つけたら4になった
ちうことで2038年までに64bit環境に移行すれという事らしい
603:login:Penguin
12/11/28 02:58:44.86 5vfkeZf4
>>601
「初心的質問」でそれ以外のアーキテクチャを
持ち出すだろうか？
604:login:Penguin
12/11/28 03:05:49.48 e8D1P1Xj
つかどう考えても>>591が言ってるのはamd64とi386のことだろ。
605:login:Penguin
12/11/28 06:17:15.56 0ObuYw3Z
ｽﾚﾘﾝｸ(tech板:620番)
スレ立てるまでもない質問はここで 122匹目で話題になってたけど、
アップデートしない組み込みLinuxはヤバそうだね。
606:login:Penguin
12/11/28 10:17:41.72 2fJdxEv6
単純な64bit化だと上4バイトは100年ぐらい使われないから
その領域を有効活用しようという輩がいるかもしれない
607:login:Penguin
12/11/28 10:35:01.64 x4Xy9KNd
>>606
COBOL世代とはビット単価が違うからなぁ
608:login:Penguin
12/11/28 16:42:42.18 C+kCIV84
アップデートしない組込環境ではtime_tうんぬん以前に脆弱性がやばい
609:login:Penguin
12/11/28 16:47:33.96 bHHFTT80
組み込みってネット繋がないじゃん
610:login:Penguin
12/11/28 17:24:41.82 lFI/pV4C
んなわけあるか
611:login:Penguin
12/11/28 20:12:30.97 U8I/LIIB
ext3では秒単位で2038年まで
612:login:Penguin
12/11/28 21:50:06.73 lh/AOkWt
ZFSの重複排除、当たり前だがメモリすげぇ食うな・・・
ファイル鯖としちゃあ便利な機能だがそんなにコストかけれないし重複排除は諦めるか
613:login:Penguin
12/11/28 21:52:57.70 hBeva0uk
メモリだけなら今安いから大したコストじゃないけど
CPUもそれなりのがいるんだろ？
614:login:Penguin
12/11/28 22:26:56.43 Ne5o68ud
>>612
なんで当たり前なん？
メモリーがたくさんいるのはなんで？
615:login:Penguin
12/11/29 00:04:45.98 o9n8bnB3
ファイル鯖にそんなCPU盛りたくないしねぇ。
ついでに他のアプリケーション動かせばいいんだろうが、なんにせよ個人じゃそんな鯖にゴリゴリさせる仕事がない。
重複排除とか圧縮かけても軽いくらいスペック盛るくらいなら、その金でHDD増設した方がいいんだよなｗ
616:login:Penguin
12/11/29 00:24:01.11 RhcfFgrp
重複排除ってどのくらいのスペックあれば快適に使えるの？
617:login:Penguin
12/11/29 08:11:56.67 5zmjOLOr
>>616
ZFSのrecordsizeによるけど、デフォだった場合、
データ1T辺り、重複排除だけで10G+ってオーダーでメモリーが必要になったはず。
L2ARCにSSDを用意しないと、メモリーから溢れた瞬間、とてつもなく遅くなる。
CPUよりメモリーの方を何とかしないとダメ。
618:login:Penguin
12/11/29 16:13:34.55 rgKmcfFs
>>612
l2arcの出番じゃね？
619:login:Penguin
12/11/29 18:36:14.17 ELpMFPV8
同一内容を検索・識別するんじゃなくて、
ファイルコピー動作とかを認識して重複排除するとかできないんだろうか？
最近読みだしたデータに限って同一判定するとか。
620:login:Penguin
12/11/29 18:54:19.39 UP0NKDBj
>>619
よく意味が分からんけど
書き込みが発生したときにブロック単位で同じのがあるかどうかを見るんじゃないの
そのテーブルがメモリをバカ食いするってことだと思うけど
621:login:Penguin
12/11/29 18:55:27.61 5r3O4WuD
それただのCoWじゃねーか？
NAS上で完結する世界ならそれでもいいけど、実際に求められてるものとは違う
622:login:Penguin
12/11/29 19:48:42.51 0qHQtO7n
重複判定できるってことは、そのぶん余計なメタデータを読み書きしないといけないんだから性能落ちるよね
623:login:Penguin
12/11/29 20:48:15.45 pjalMcgj
重複排除によって無くなった行われるはずだったユーザーデータの書き込み量のほうが多いかもしれない
624:login:Penguin
12/11/29 20:57:57.56 8G72Uq2S
>>623
クラウド、VPSの仮想HDDの中の/bin以下のファイルみたいなかなり特殊な用途？
625:login:Penguin
12/11/29 23:13:38.69 pDJO4XkO
XFSを褒め殺しにしていると疑われているオレ様がやってきましたよ
褒め殺しではない
純粋に褒めているし実際に使っている
叩いた事など神に誓ってない
ZFSなら叩きたい
626:login:Penguin
12/11/29 23:19:38.18 Fy7iUFEH
そっか よかったね
627:login:Penguin
12/11/30 07:52:53.99 +IUiRuU3
XFSとZFSの良いとこ取りの新ファイルシステム YFS
628:login:Penguin
12/11/30 11:19:43.24 O6Mkk6WA
>>619
特定の状況だけ適用してもらいたいんならその状況時にユーザーモード側でioctl発行しろと返されんのがオチ
629:login:Penguin
12/11/30 13:06:34.15 MBudbpC1
>>618
HDD増やした方がコスパよくね？業務に使うならともかく個人ならな
630:login:Penguin
12/11/30 13:20:22.58 97UtYzmP
同じ形式のファイルをテラ単位で扱うような用途じゃないとあまり恩恵はないだろうな
少なくても自分は容量食ってるのは動画とか音楽とか写真だから全く意味無い
631:login:Penguin
12/11/30 14:41:02.44 +IUiRuU3
仮想マシンのファイルはほとんど同じなので、
重複排除でバンザーイと思って、Virutalboxと
ZFSの組み合わせを試してみた事がある。
ほとんど重複排除の効果は無く、一時停止で保存した
ファイルでゲストOSが再開できないとか、逆の意味で
バンザーイの結果だった。
632:login:Penguin
12/11/30 14:45:50.73 XBMblfhY
世代バックアップとか
633:login:Penguin
12/11/30 19:14:17.65 +U2+nr9a
ハードリンクで済むような
634:login:Penguin
12/11/30 20:43:12.76 c5zYVaPD
大きいファイルの世代バックアップには有効そうなんじゃない?
何ギガもあるsqliteファイルとか。
635:login:Penguin
12/11/30 20:46:57.15 +d+9eytJ
バックアップになってるのかそれ
前にもそんな議論があったような
636:login:Penguin
12/11/30 20:50:49.19 Wbr1Hrjf
まあ核攻撃に耐えられなければバックアップとは言えないからなあ
バックアップでないものをバックアップと言う人が多いよ
まったく
637:login:Penguin
12/11/30 20:56:39.55 +d+9eytJ
前の議論もそうだけど
勝手にバックアップのハードル上げてるだけだと思うが
638:login:Penguin
12/11/30 21:21:07.01 cH0j9TJP
月面データセンターだと万全のバックアップできる
応答時間に数秒要するからバックアップにしか使えないけど
639:login:Penguin
12/12/01 11:06:30.84 57GOA1iw
月は出ているか？
ってガンダムXごっこができるな。
スペースデブリの月面DCへの影響は無視してもいいよね。
640:login:Penguin
12/12/01 11:11:57.60 u17Es2jQ
電磁波って宇宙だと減衰しないから
宇宙に向けて全データを電磁波の形で発信しておけば
少なくともこの宇宙がなくなるまでは保存されるな。
641:login:Penguin
12/12/01 11:43:54.49 N7ftY3AP
>>640
その発信したデータを読みたければ、電磁波より速く飛んで先回りして受信しなければならないのでは
642:login:Penguin
12/12/01 12:13:10.05 NaDxh72b
え？ｗ突っ込むとこそこかよｗｗ
文系かよｗ
643:login:Penguin
12/12/01 15:37:17.27 RSbxRGIT
ZFSの重複排除ってメモリに蓄えるから、
不意の電源OFFだと全部破壊されちゃうんだよね
それだとバックアップに使うのは怖いな
644:login:Penguin
12/12/01 15:39:14.11 YCftnAyr
んなわけない
645:login:Penguin
12/12/01 16:17:37.35 ahLWJFql
>>643みたいな幼稚な人が作ってるファイルシステムあったら教えて下さい。
646:login:Penguin
12/12/02 11:30:19.75 7/pq8/aL
>>640
波長によって激しく減衰する、宇宙は完全な真空ではなく万年やら億年
経過したそれが何も影響しないというのはアフォ。
647:login:Penguin
12/12/02 19:04:34.13 mVabdcTi
>>645
ZFS
648:login:Penguin
12/12/02 23:00:00.47 rtnvhs7J
ファイルシステムとバックアップは分けて考えなければいけない
649:login:Penguin
12/12/03 00:59:53.94 NL3l4q/N
分けて考えないのが近年の高機能ファイルシステムでしょ！
650:login:Penguin
12/12/03 02:01:26.58 m+hsgesp
>>649
って誰が言ってるの？
651:login:Penguin
12/12/03 07:50:17.46 XMtYyBax
俺だよ。この俺が言ってんだし間違いない。
652:login:Penguin
12/12/03 09:12:19.30 IatjFUis
この前、自分定義のバックアップって言葉使って馬鹿にされた馬鹿が
粘着してるなぁ。
653:login:Penguin
12/12/03 19:51:06.32 jsdeVSEB
>>651
ソースは2ch (笑)
654:login:Penguin
12/12/03 20:16:29.29 OnmaiFIf
その時馬鹿にした連中の方が勝手な定義してたな
655:login:Penguin
12/12/04 02:47:31.73 /MyXzNsh
しつこいよ
656:login:Penguin
12/12/04 11:58:42.03 0MaVXl3z
>>654
お前、本当に馬鹿なんだな…
657:login:Penguin
12/12/04 12:10:59.15 4OSV5gGC
定義なんて話の都度擦り合わせればいいのよ。
658:login:Penguin
12/12/04 12:19:44.14 /MyXzNsh
はいはいビールジョッキ思想
659:login:Penguin
12/12/07 03:38:12.68 Kmapfwof
zfs-win - ZFS for Windows
URLﾘﾝｸ(code.google.com)
あるにはあるんやな
660:login:Penguin
12/12/11 10:48:11.30 OC3w0rBs
ZFSのファイルシステムにMysqlのデータを置いた環境があり、
某システムの評価で圧縮して400MバイトのMysqlのダンプファイルを
インポートしてみた。
平時はあまり使われない、Logsの領域にも激しく書き込みがあり、
Logsのallocの領域がみるみる増えて行く。raidz1のディスクで30MB/sec
Logsの30MB/secと合計で60MB/secの書き込みが出来て、ZFSの
実力の一部が判った。
661:login:Penguin
12/12/11 20:46:17.33 xycx3/qX
XFSが3.7でinode64がデフォルトになるから3.6以前に持ってく時は気を付けろー
URLﾘﾝｸ(kernelnewbies.org)
662:login:Penguin
12/12/24 22:27:48.15 sbyUtyUS
なんでext4には作成日時のタイムスタンプがないの？
663:login:Penguin
12/12/24 22:40:45.97 E6q8YXZl
>>662
いや、あるよ。
664:login:Penguin
12/12/24 23:08:00.12 eKE+nVHw
ctime無いのはFAT位でないかい
665:login:Penguin
12/12/25 00:49:11.63 1QXwWvF5
ctimeってリンク数増やしたりとかしたら変わらないかい
666:login:Penguin
12/12/25 01:24:41.49 nEcZEp+3
それはmtime
667:login:Penguin
12/12/25 10:35:35.06 IP+RDtTj
ZFS Linux Native RC13が出てました。
いろいろ直っているみたいだが、ウチの
自宅サーバでは何の問題無く動いているので、
違いが判らん。
668:login:Penguin
12/12/25 11:38:28.45 h2WGgx8H
ctimeとcrtimeは混同してはいけない
669:login:Penguin
12/12/25 11:43:42.21 Y1A2QGKN
birth time があるよ
670:login:Penguin
12/12/25 12:05:30.52 XahNtSbC
>>666
誤り
mtimeが変わるのはファイルの内容を書き換えた時
リンクカウントの増減はメタデータだけの変更に当たる
671:login:Penguin
12/12/25 15:42:44.80 p7dp1Rj6
ctime をファイル作成日時だと勘違いしてるやつがいるのか?
672:login:Penguin
12/12/28 05:03:18.35 Isi4WQd9
NTFS ボリューム上で新規ファイルが作成できない現象について
URLﾘﾝｸ(blogs.technet.com)
$Secure のデータは少しずつ登録される事が多く、非常にフラグメントが発生しやすい環境です。
$Secure のフラグメントが解消される事で、登録できるセキュリティ記述子の数が増える事が期待できます。
Windows7 / Windows Server 2008 R2 以降の環境で発生した場合には、まずはデフラグの実施をご検討ください。
※ 現在、Windows 7 / Windows Server 2008 R2 環境でデフラグを実施したところ、反対に $Secure の File Record 数が増えてしまったという報告を受けています。
詳細が確認出来次第この記事をアップデートいたしますので、それまで $Secure の ATTRIBUTE_LIST を減らす事を目的としたデフラグの実施はお待ちください。
;(；ﾞﾟ'ωﾟ');
673:login:Penguin
12/12/31 04:28:13.37 dAiNz+QV
raidz や raidz2 で、玉を増やすほうの grow が出来るようにならないかなあ。
674:login:Penguin
13/01/01 21:53:27.45 Nww2FIpd
>>672
その地雷を最初に踏んだ人がどれだけ悩んだか
話を聞いてみたい
675:login:Penguin
13/01/06 23:12:39.85 kYUtqyri
重複排除と透過圧縮とファイルのチェックサムの機能がある
ファイルシステムってZFSだけでしょうか?
調べてみるとlessfsは重複排除と圧縮機能があるみたいですがチェックサムはなさそうで
ext4とbtrfsは圧縮とチェックサムがあって重複排除はない(btrfsは実装予定?)みたいです
676:login:Penguin
13/01/06 23:35:38.20 Re23CH8E
>>675
URLﾘﾝｸ(en.wikipedia.org)
677:login:Penguin
13/01/07 10:19:35.98 0RviA27S
ext4のチェックサムってメタデータだけでしょ
678:login:Penguin
13/01/07 12:19:52.72 AWuj5r3N
データが化けてもメタデータさえOKならファイルシステムの整合性は完璧だからな。
679:login:Penguin
13/01/07 20:13:16.34 ZaqHohDc
ファイルが壊れてもファイルシステムが壊れなければ意味があるっ
680:login:Penguin
13/01/07 21:30:47.50 zbCcU4Hg
raid5+xfsでデータ化けするて聞いたんだけど
raid5で1ディスクの1ブロックだけ化けた場合でも修復できないんだっけ？
681:login:Penguin
13/01/07 22:40:40.63 RNyulshO
釣りか？ ソフトウェアRAID だろうが、ハードウェアRAID だろうが、RAID5 と
ファイルシステムではレイヤーが違うから「RAID5+xfsでデータ化ける」なんてことはない。
データが化けるのは別の原因で xfs 以外のファイルシステムにしたときに、たまたまその
ブロックを踏まなかったってだけだろ。
この場合ハードウェアRAID が何らかの故障を抱えているんだと思う。
ただ、アクセス速度を上げるために、パリティチェックしない製品／設定がある
(ハードディスクに全くアクセスできない場合のみパリティから修復)らしいので、
「raid5で１ディスクの１ブロックだけ化けた場合でも修復できない」事はありえるが。
682:login:Penguin
13/01/07 22:57:19.54 zbCcU4Hg
ディスク3台で A,B,パリティ になってる所で
パリティ部分がデータ化けしたらそのブロックは修復できんの？
683:login:Penguin
13/01/07 23:57:05.50 JEVZzUqP
RAID5ではどっちみち化けたら修復できない。どっちが正しいか判別できないからだ。
RAID-Zなら別だがな。
684:login:Penguin
13/01/08 00:00:55.60 8lDKm/Dg
なるほどね、勉強になった
685:login:Penguin
13/01/08 00:28:39.57 Atou43r/
1ビットのパリティは1ビット以内の誤りを検出できるだけだからな。
化けられたらどうしようもない。
運を天に任せて1台切り離せば読めるかもしれないぞ。