トップページ⇒linux
1001コメント248KB

ファイルシステム総合スレ その15

■ このスレッドは過去ログ倉庫に格納されています
0001login:Penguin;2012/06/30(土) 08:36:00.10ID:q3w7kzQB
●前スレ ファイルシステム総合スレ その14
http://engawa.2ch.net/test/read.cgi/linux/1326613113/
●関連スレ
ジャーナリングファイルシステム
http://toro.2ch.net/test/read.cgi/unix/979408065/
OpenSolaris/Illumos (OpenIndiana, etc.) 6
http://toro.2ch.net/test/read.cgi/unix/1337411922/
FS関連スレ
http://kohada.2ch.net/test/read.cgi/os/1137387538/l50
過去スレ、関連リンクは >>2-10 あたりで。
0577login:Penguin2012/11/23(金) 21:06:42.92ID:unSoxewK
>>576
FATディスクフォーマットのタイムスタンプが累計秒数で記録されていると思ってないか
0578login:Penguin2012/11/23(金) 23:43:26.49ID:B796Zs33
ttp://free.pjc.co.jp/fat/mem/fatfile2.html
FATは年(7)/月(4)/日(5) 時(5):分(6):秒(5)と
カッコの数だけビットを割り当てて管理してるので
2048年に何か問題が起こるとは思えない
7bit確保されてるので1980+127=2107年まで大丈夫

でもDOSが内部的にどう時間を管理してるのかよく知らない
2048年に何か起こるんですか？
0579login:Penguin2012/11/24(土) 00:31:42.14ID:PEn0woT6
>>578
ファイルシステム上は問題は起きないが、ファイルのタイムスタンプを1980年1月1日深夜0時ジャストからの経過秒数として32bit整数で保持しているプログラムが正常に動作しなくなる。

……ただし、そんなプログラムが実在するかは知らない。
0580login:Penguin2012/11/24(土) 00:53:51.90ID:tmvWLVRx
DOSの時間系関数を使って管理してるDOSアプリには2048年問題は起こらない
ダメなのはC標準関数使ってるDOSアプリということですね
UNIXからFATをフォーマットしてる場合は48年以前に38年問題にひっかかるわけですし
0581login:Penguin2012/11/24(土) 00:57:26.99ID:tmvWLVRx
×フォーマット
○マウント
0582login:Penguin2012/11/24(土) 01:12:53.22ID:tmvWLVRx
いや、やっぱりC標準関数は1970年を基点とするからそれはないだろうな
FATで0x0000 0x0000というタイムスタンプのファイルがあったとして
それはエポック秒で315500400と変換されてしまうから48年問題は起こりそうにない
アプリで独自に符号付32bit値として保有してる場合だけに48年問題は起こる
こんなアプリ作ってる人いるんかいな？
0583login:Penguin2012/11/24(土) 01:35:11.25ID: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 を使うもの全般が、ファイルシステムに関係なくまずいのかな。
0584login:Penguin2012/11/24(土) 01:39:16.07ID:Khi9rNEZ
>>583
くっついてるw

× > 　/usr/include/bits/types.h:103:#define __SLONGWORD_TYPElong int
○ > 　/usr/include/bits/types.h:103:#define __SLONGWORD_TYPE long int
0585login:Penguin2012/11/24(土) 01:52:10.32ID:ynQbzFjy
time_tの正体が何かはシステムによって違うでしょ。
0586login:Penguin2012/11/26(月) 11:57:20.62ID:5um68ud/
>>464
＞time_tはカーネルの64bit化とは関係なく、既に64bit化されてる。
まじで？
time_tが64bit化されたlibcのバージョン教えてくださいおねがいします
0587login:Penguin2012/11/26(月) 17:41:47.54ID:fgUG4e/Q
GNU libcではtime_tはlong intであってlong intの大きさは処理系定義なので
まあきっとあってもおかしくはないとかなんとかかんとか
0588login:Penguin2012/11/26(月) 17:55:27.87ID:kLZfMEml
32ビットでフォーマットされているものを突然64ビットで扱おうとして
データを壊しまくるファイルシステムｗ
0589login:Penguin2012/11/26(月) 21:05:38.16ID:AuvtZE0G
>>586
＞>>464
＞＞time_tはカーネルの64bit化とは関係なく、既に64bit化されてる。


ubuntu 12 i386でsizeof time_tをprintしてけど32bitだ
0590login:Penguin2012/11/27(火) 03:27:25.68ID:Z/NY1RrE
Ubuntuは32bitということですが
64bitに対応したLinuxディストリビューションはどれになりますか？
0591login:Penguin2012/11/27(火) 04:23:12.75ID:Z/NY1RrE
あと初歩的な質問になりますが
32bitのLinuxからも、64bitのLinuxからも、
同一のファイルシステムをmountして問題なく扱えますよね？
例えば、ファイルのタイムスタンプの扱いが気になるのですが、
そこは、どちらにしてもファイルシステムの仕様通りに
きちんと処理してくれているということでしょうか。
0592login:Penguin2012/11/27(火) 20:37:59.37ID:4DO8DdDv
Ubuntuにも64bitなかったっけ
マウントの問題は大丈夫
0593login:Penguin2012/11/27(火) 21:02:09.58ID:yZTntV89
__STD_TYPE __TIME_T_TYPE __time_t; /* Seconds since the Epoch. */
0594login:Penguin2012/11/27(火) 21:11:04.70ID:Z/NY1RrE
>>592
Ubuntuに64bitありますね
ありがとうございます
0595login:Penguin2012/11/27(火) 21:17:04.40ID:eYUehpwt
#include <time.h>
#include <stdio.h>

int main(void)
{
　printf("%d\n", sizeof(time_t));
}

8だった@Debian sid/amd64
0596login:Penguin2012/11/27(火) 21:32:19.31ID:+FTMVYlJ
ちょww8ビットてww
0597login:Penguin2012/11/27(火) 21:34:21.94ID:yZTntV89
8bytes
0598login:Penguin2012/11/27(火) 22:03:33.10ID:2Faa51y/
>>595のやつ
Debian6.0.6@amd64(サーバー)
Ubuntu12.10@amd64(デスクトップ)

どっちも8でした
0599login:Penguin2012/11/27(火) 23:05:11.14ID:P3Z6acGK
>>591
x86とAMD64で何が違うのかをもうちょっと知れば、そういう質問は出てこない気がするなあ。
0600login:Penguin2012/11/27(火) 23:56:12.21ID: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 ([email protected]) (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化されてる。 」
と矛盾してないのか？
0601login:Penguin2012/11/27(火) 23:57:18.46ID:+wYW/dtS
>>599
32bitと64bitとしか書いてないからx86とamd64とは限らない。
というかその二つに限定すると理解が疑われかねんな。
06025952012/11/28(水) 02:17:16.58ID:nx7Okma8
なんとなく気になったので同じ環境で-m32つけたら4になった
ちうことで2038年までに64bit環境に移行すれという事らしい
0603login:Penguin2012/11/28(水) 02:58:44.86ID:5vfkeZf4
>>601
「初心的質問」でそれ以外のアーキテクチャを
持ち出すだろうか？
0604login:Penguin2012/11/28(水) 03:05:49.48ID:e8D1P1Xj
つかどう考えても>>591が言ってるのはamd64とi386のことだろ。
0605login:Penguin2012/11/28(水) 06:17:15.56ID:0ObuYw3Z
ttp://toro.2ch.net/test/read.cgi/tech/1351769173/620
スレ立てるまでもない質問はここで 122匹目で話題になってたけど、
アップデートしない組み込みLinuxはヤバそうだね。
0606login:Penguin2012/11/28(水) 10:17:41.72ID:2fJdxEv6
単純な64bit化だと上4バイトは100年ぐらい使われないから
その領域を有効活用しようという輩がいるかもしれない
0607login:Penguin2012/11/28(水) 10:35:01.64ID:x4Xy9KNd
>>606
COBOL世代とはビット単価が違うからなぁ
0608login:Penguin2012/11/28(水) 16:42:42.18ID:C+kCIV84
アップデートしない組込環境ではtime_tうんぬん以前に脆弱性がやばい
0609login:Penguin2012/11/28(水) 16:47:33.96ID:bHHFTT80
組み込みってネット繋がないじゃん
0610login:Penguin2012/11/28(水) 17:24:41.82ID:lFI/pV4C
んなわけあるか
0611login:Penguin2012/11/28(水) 20:12:30.97ID:U8I/LIIB
ext3では秒単位で2038年まで
0612login:Penguin2012/11/28(水) 21:50:06.73ID:lh/AOkWt
ZFSの重複排除、当たり前だがメモリすげぇ食うな・・・
ファイル鯖としちゃあ便利な機能だがそんなにコストかけれないし重複排除は諦めるか
0613login:Penguin2012/11/28(水) 21:52:57.70ID:hBeva0uk
メモリだけなら今安いから大したコストじゃないけど
CPUもそれなりのがいるんだろ？
0614login:Penguin2012/11/28(水) 22:26:56.43ID:Ne5o68ud
>>612
なんで当たり前なん？
メモリーがたくさんいるのはなんで？
0615login:Penguin2012/11/29(木) 00:04:45.98ID:o9n8bnB3
ファイル鯖にそんなCPU盛りたくないしねぇ。
ついでに他のアプリケーション動かせばいいんだろうが、なんにせよ個人じゃそんな鯖にゴリゴリさせる仕事がない。
重複排除とか圧縮かけても軽いくらいスペック盛るくらいなら、その金でHDD増設した方がいいんだよなｗ
0616login:Penguin2012/11/29(木) 00:24:01.11ID:RhcfFgrp
重複排除ってどのくらいのスペックあれば快適に使えるの？
0617login:Penguin2012/11/29(木) 08:11:56.67ID:5zmjOLOr
>>616
ZFSのrecordsizeによるけど、デフォだった場合、
データ1T辺り、重複排除だけで10G+ってオーダーでメモリーが必要になったはず。
L2ARCにSSDを用意しないと、メモリーから溢れた瞬間、とてつもなく遅くなる。
CPUよりメモリーの方を何とかしないとダメ。
0618login:Penguin2012/11/29(木) 16:13:34.55ID:rgKmcfFs
>>612
l2arcの出番じゃね？
0619login:Penguin2012/11/29(木) 18:36:14.17ID:ELpMFPV8
同一内容を検索・識別するんじゃなくて、
ファイルコピー動作とかを認識して重複排除するとかできないんだろうか？
最近読みだしたデータに限って同一判定するとか。
0620login:Penguin2012/11/29(木) 18:54:19.39ID:UP0NKDBj
>>619
よく意味が分からんけど
書き込みが発生したときにブロック単位で同じのがあるかどうかを見るんじゃないの
そのテーブルがメモリをバカ食いするってことだと思うけど
0621login:Penguin2012/11/29(木) 18:55:27.61ID:5r3O4WuD
それただのCoWじゃねーか？

NAS上で完結する世界ならそれでもいいけど、実際に求められてるものとは違う
0622login:Penguin2012/11/29(木) 19:48:42.51ID:0qHQtO7n
重複判定できるってことは、そのぶん余計なメタデータを読み書きしないといけないんだから性能落ちるよね
0623login:Penguin2012/11/29(木) 20:48:15.45ID:pjalMcgj
重複排除によって無くなった行われるはずだったユーザーデータの書き込み量のほうが多いかもしれない
0624login:Penguin2012/11/29(木) 20:57:57.56ID:8G72Uq2S
>>623
クラウド、VPSの仮想HDDの中の/bin以下のファイルみたいなかなり特殊な用途？
0625login:Penguin2012/11/29(木) 23:13:38.69ID:pDJO4XkO
XFSを褒め殺しにしていると疑われているオレ様がやってきましたよ

褒め殺しではない
純粋に褒めているし実際に使っている

叩いた事など神に誓ってない
ZFSなら叩きたい
0626login:Penguin2012/11/29(木) 23:19:38.18ID:Fy7iUFEH
そっか　よかったね
0627login:Penguin2012/11/30(金) 07:52:53.99ID:+IUiRuU3
XFSとZFSの良いとこ取りの新ファイルシステム YFS
0628login:Penguin2012/11/30(金) 11:19:43.24ID:O6Mkk6WA
>>619
特定の状況だけ適用してもらいたいんならその状況時にユーザーモード側でioctl発行しろと返されんのがオチ
0629login:Penguin2012/11/30(金) 13:06:34.15ID:MBudbpC1
>>618
HDD増やした方がコスパよくね？業務に使うならともかく個人ならな
0630login:Penguin2012/11/30(金) 13:20:22.58ID:97UtYzmP
同じ形式のファイルをテラ単位で扱うような用途じゃないとあまり恩恵はないだろうな
少なくても自分は容量食ってるのは動画とか音楽とか写真だから全く意味無い
0631login:Penguin2012/11/30(金) 14:41:02.44ID:+IUiRuU3
仮想マシンのファイルはほとんど同じなので、
重複排除でバンザーイと思って、Virutalboxと
ZFSの組み合わせを試してみた事がある。

ほとんど重複排除の効果は無く、一時停止で保存した
ファイルでゲストOSが再開できないとか、逆の意味で
バンザーイの結果だった。
0632login:Penguin2012/11/30(金) 14:45:50.73ID:XBMblfhY
世代バックアップとか
0633login:Penguin2012/11/30(金) 19:14:17.65ID:+U2+nr9a
ハードリンクで済むような
0634login:Penguin2012/11/30(金) 20:43:12.76ID:c5zYVaPD
大きいファイルの世代バックアップには有効そうなんじゃない?
何ギガもあるsqliteファイルとか。
0635login:Penguin2012/11/30(金) 20:46:57.15ID:+d+9eytJ
バックアップになってるのかそれ
前にもそんな議論があったような
0636login:Penguin2012/11/30(金) 20:50:49.19ID:Wbr1Hrjf
まあ核攻撃に耐えられなければバックアップとは言えないからなあ
バックアップでないものをバックアップと言う人が多いよ
まったく
0637login:Penguin2012/11/30(金) 20:56:39.55ID:+d+9eytJ
前の議論もそうだけど
勝手にバックアップのハードル上げてるだけだと思うが
0638login:Penguin2012/11/30(金) 21:21:07.01ID:cH0j9TJP
月面データセンターだと万全のバックアップできる

応答時間に数秒要するからバックアップにしか使えないけど
0639login:Penguin2012/12/01(土) 11:06:30.84ID:57GOA1iw
月は出ているか？
ってガンダムXごっこができるな。

スペースデブリの月面DCへの影響は無視してもいいよね。
0640login:Penguin2012/12/01(土) 11:11:57.60ID:u17Es2jQ
電磁波って宇宙だと減衰しないから
宇宙に向けて全データを電磁波の形で発信しておけば
少なくともこの宇宙がなくなるまでは保存されるな。
0641login:Penguin2012/12/01(土) 11:43:54.49ID:N7ftY3AP
>>640
その発信したデータを読みたければ、電磁波より速く飛んで先回りして受信しなければならないのでは
0642login:Penguin2012/12/01(土) 12:13:10.05ID:NaDxh72b
え？ｗ突っ込むとこそこかよｗｗ
文系かよｗ
0643login:Penguin2012/12/01(土) 15:37:17.27ID:RSbxRGIT
ZFSの重複排除ってメモリに蓄えるから、
不意の電源OFFだと全部破壊されちゃうんだよね
それだとバックアップに使うのは怖いな
0644login:Penguin2012/12/01(土) 15:39:14.11ID:YCftnAyr
んなわけない
0645login:Penguin2012/12/01(土) 16:17:37.35ID:ahLWJFql
>>643みたいな幼稚な人が作ってるファイルシステムあったら教えて下さい。
0646login:Penguin2012/12/02(日) 11:30:19.75ID:7/pq8/aL
>>640
波長によって激しく減衰する、宇宙は完全な真空ではなく万年やら億年
経過したそれが何も影響しないというのはアフォ。
0647login:Penguin2012/12/02(日) 19:04:34.13ID:mVabdcTi
>>645
ZFS
0648login:Penguin2012/12/02(日) 23:00:00.47ID:rtnvhs7J
ファイルシステムとバックアップは分けて考えなければいけない
0649login:Penguin2012/12/03(月) 00:59:53.94ID:NL3l4q/N
分けて考えないのが近年の高機能ファイルシステムでしょ！
0650login:Penguin2012/12/03(月) 02:01:26.58ID:m+hsgesp
>>649
って誰が言ってるの？
0651login:Penguin2012/12/03(月) 07:50:17.46ID:XMtYyBax
俺だよ。この俺が言ってんだし間違いない。
0652login:Penguin2012/12/03(月) 09:12:19.30ID:IatjFUis
この前、自分定義のバックアップって言葉使って馬鹿にされた馬鹿が
粘着してるなぁ。
0653login:Penguin2012/12/03(月) 19:51:06.32ID:jsdeVSEB
>>651
ソースは2ch (笑)
0654login:Penguin2012/12/03(月) 20:16:29.29ID:OnmaiFIf
その時馬鹿にした連中の方が勝手な定義してたな
0655login:Penguin2012/12/04(火) 02:47:31.73ID:/MyXzNsh
しつこいよ
0656login:Penguin2012/12/04(火) 11:58:42.03ID:0MaVXl3z
>>654
お前、本当に馬鹿なんだな…
0657login:Penguin2012/12/04(火) 12:10:59.15ID:4OSV5gGC
定義なんて話の都度擦り合わせればいいのよ。
0658login:Penguin2012/12/04(火) 12:19:44.14ID:/MyXzNsh
はいはいビールジョッキ思想
0659login:Penguin2012/12/07(金) 03:38:12.68ID:Kmapfwof
zfs-win - ZFS for Windows
http://code.google.com/p/zfs-win/

あるにはあるんやな
0660login:Penguin2012/12/11(火) 10:48:11.30ID:OC3w0rBs
ZFSのファイルシステムにMysqlのデータを置いた環境があり、
某システムの評価で圧縮して400MバイトのMysqlのダンプファイルを
インポートしてみた。

平時はあまり使われない、Logsの領域にも激しく書き込みがあり、
Logsのallocの領域がみるみる増えて行く。raidz1のディスクで30MB/sec
Logsの30MB/secと合計で60MB/secの書き込みが出来て、ZFSの
実力の一部が判った。
0661login:Penguin2012/12/11(火) 20:46:17.33ID:xycx3/qX
XFSが3.7でinode64がデフォルトになるから3.6以前に持ってく時は気を付けろー
http://kernelnewbies.org/Linux_3.7
0662login:Penguin2012/12/24(月) 22:27:48.15ID:sbyUtyUS
なんでext4には作成日時のタイムスタンプがないの？
0663login:Penguin2012/12/24(月) 22:40:45.97ID:E6q8YXZl
>>662
いや、あるよ。
0664login:Penguin2012/12/24(月) 23:08:00.12ID:eKE+nVHw
ctime無いのはFAT位でないかい
0665login:Penguin2012/12/25(火) 00:49:11.63ID:1QXwWvF5
ctimeってリンク数増やしたりとかしたら変わらないかい
0666login:Penguin2012/12/25(火) 01:24:41.49ID:nEcZEp+3
それはmtime
0667login:Penguin2012/12/25(火) 10:35:35.06ID:IP+RDtTj
ZFS Linux Native RC13が出てました。
いろいろ直っているみたいだが、ウチの
自宅サーバでは何の問題無く動いているので、
違いが判らん。
0668login:Penguin2012/12/25(火) 11:38:28.45ID:h2WGgx8H
ctimeとcrtimeは混同してはいけない
0669login:Penguin2012/12/25(火) 11:43:42.21ID:Y1A2QGKN
birth time があるよ
0670login:Penguin2012/12/25(火) 12:05:30.52ID:XahNtSbC
>>666
誤り
mtimeが変わるのはファイルの内容を書き換えた時
リンクカウントの増減はメタデータだけの変更に当たる
0671login:Penguin2012/12/25(火) 15:42:44.80ID:p7dp1Rj6
ctime をファイル作成日時だと勘違いしてるやつがいるのか?
0672login:Penguin2012/12/28(金) 05:03:18.35ID:Isi4WQd9
NTFS ボリューム上で新規ファイルが作成できない現象について
http://blogs.technet.com/b/askcorejp/archive/2010/04/26/ntfs.aspx

$Secure のデータは少しずつ登録される事が多く、非常にフラグメントが発生しやすい環境です。
$Secure のフラグメントが解消される事で、登録できるセキュリティ記述子の数が増える事が期待できます。
Windows7 / Windows Server 2008 R2 以降の環境で発生した場合には、まずはデフラグの実施をご検討ください。

※ 現在、Windows 7 / Windows Server 2008 R2 環境でデフラグを実施したところ、反対に $Secure の File Record 数が増えてしまったという報告を受けています。
詳細が確認出来次第この記事をアップデートいたしますので、それまで $Secure の ATTRIBUTE_LIST を減らす事を目的としたデフラグの実施はお待ちください。


;(；ﾞﾟ'ωﾟ');
0673login:Penguin2012/12/31(月) 04:28:13.37ID:dAiNz+QV
raidz や raidz2 で、玉を増やすほうの grow が出来るようにならないかなあ。
0674login:Penguin2013/01/01(火) 21:53:27.45ID:Nww2FIpd
>>672
その地雷を最初に踏んだ人がどれだけ悩んだか
話を聞いてみたい
0675login:Penguin2013/01/06(日) 23:12:39.85ID:kYUtqyri
重複排除と透過圧縮とファイルのチェックサムの機能がある
ファイルシステムってZFSだけでしょうか?
調べてみるとlessfsは重複排除と圧縮機能があるみたいですがチェックサムはなさそうで
ext4とbtrfsは圧縮とチェックサムがあって重複排除はない(btrfsは実装予定?)みたいです
0676login:Penguin2013/01/06(日) 23:35:38.20ID:Re23CH8E
>>675
http://en.wikipedia.org/wiki/Comparison_of_file_systems
■ このスレッドは過去ログ倉庫に格納されています