アカウント名:
パスワード:
邪悪な Oracle が邪魔しなければ、とっくの昔に ZFS に移行していたであろうにな。
動いているコンピュータのファイルシステムを変更するのか。環境の統一性を重視するAppleだが、ここまでやるか。
動いてないコンピュータのファイルシステムを変更するほうが難しいと思うよ。
うろ覚えだけど、Windows 98のFAT32コンバータだって動いているファイルシステムの変更でしょ。ここまでやるか、って言う程の処理なのか?リスクが高いから滅多にやらないものではあるだろうけれど。
言われてみればFAT32 -> NTFSもできたね。ただ、強制的にやるのは珍しいかも。
あー、確かに強制ってのは聞いたことないね。まあ、Appleらしさだねぇ。MSがやったら絶対に非難囂々だなぁ。ハードウェア環境も多岐にわたるから、失敗するマシンも出るだろうし。
iPhoneって外部からはドライブとして認識されることはないから、ということもあるよね。
今のAndroidも外部からドライブとして認識されること無いんだけど。今時外部からドライブとして認識されるスマホってあんの?
> 今時外部からドライブとして認識されるスマホってあんの?
プロトコルとしてMTP/PTPではなくMSCにしているとPCからは一般的なドライブとして見える
スマホの機種によってはMSCモードでは物理的SDしかPCに見せない(内蔵ストレージはPCに見せない)ようにするなどセキュリティを考慮した実装が追加されているものもある
それってもしかして、ファイルシステムでのUnicode正規化をやめたから?# ZFSが欲しかったなぁ、とは思ったもんだが、それならWatchにはリソース不足で積めないし、これでよかったのかなぁ
昔のNTFSはそうでもなかった。まあ歳月はファイルシステムを変えるということだな。
KT7.5でHFSから使ってますが、修復不能になった経験は一度もありません。チェックで軽微なエラーはよく出てましたけど。
8.1からはHFS+もすぐ使い始めましたけど、同様に重大なエラーに遭ったことはないです。
MacOSXもPublicBetaから使ってますが、ジャーナリング無しで特に問題が出たこともないです。(ジャーナリング機能は10.2以降(サーバ版のみ有効。一般向けはコマンドで有効化可能)、正式には10.3から)
G3Macに40GBのHDD入れて1パーティションで使ってて、Speed Diskかけたらシステムファイル?が8GBの壁を越えてしまい、うっかり起動不能になったぐらいか。これは自業自得。
ちゃんと切断しないやつが悪い
> こう考えるとNTFSなWindowsは堅牢よね。
NTFS以上に多様なHWで荒い使われ方するFSなんてないからね。# 強いて言うとFATか
やめたという情報源はどこに?その辺は継承のようだけど合成除外の扱いを変えたらいいのに
http://naruse.hateblo.jp/entry/2017/03/28/181519 [hateblo.jp]
これだけでは分解をやめただけなのか合成するようになったのか判断が付きませんなぁ// いやまあわざわざやることはないだろうけどさ
「NFDで作ったらNFDのままだった」という記事やツイートと「NFCで作ったらNFCのままだった」という記事の両方があったので、合わせると分解をやめたと推測できる。
なんで誰も1つの記事で両方テストしていないのかは謎。
HFS+から移行した場合、既存のファイル名はNFD分解したままだよね?その場所に、NFCの同じファイル名を作成するとどうなるんだ?
ZFSはメモリ的に無理じゃないかなMacOSならともかくios では辛い
投入は2018年とか聞いてたんだけど、10.3とかいう中途半端なバージョン番号でいきなり投入なんて、なにか政治的な理由で前倒しになったの?ファイルシステムのバグ取りって結構時間かかるもんじゃないのかな、btrfsの悪口言う訳じゃないけど…
ユーザーに使ってもらってまさにバグ取りをしようというだけではないでしょうか。母数多いからはかどる
Mapsで [apple.srad.jp] 一騒動やらかして [apple.srad.jp]、中の人もそういうやんちゃが引き起こす結果については懲りてるんじゃないかな。
次のiPhoneやiPadでもうインテルx86化(+MacOSXとの実装統合)していくのでしょうそれに備えて既存のARMの端末で新FSの人柱強制(いわゆる有償ベータテスター)させつつ、インテルx86版のiPhoneやiPadと同時ではなく先に移行させておきたいと考えるのは自然なことです
何故、MacのARM化は想定しなかったのかw
APFS?APFSDS?APDS-FS?ワケワカメ
# オフトピでサーセン
linuxやOSを勉強しているとある段階で必ずファイルシステムが出てくる、ぼんやりとは分かっているけど分からないところがあるまずファイルを物理的に読み書きするとき最終的にストレージのコントローラーが用意してる共通APIがあってそれで制御しているのかOSのAPIでコントローラに命令してるのか良く分からない次にlinuxで扱うファイルシステムがOSのカーネルに取り込まれていなくて外部ソフトを通して読み書きする場合そのファイルシステムをlinuxがどう見てるのか分からない(ユーザーが関知するする部分ではないがOSに興味があるので調べている)この二点ヒントだけでも教えて欲しい
もはや和ゴミと並ぶスラド名物ですな
あれは(意図的に似せてるのを除くと)ほぼ同一人物ってわかるからネタになるけどApple関連はいまいち「あ、あの人だ」みたいな感じがないから面白味に欠ける
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
吾輩はリファレンスである。名前はまだ無い -- perlの中の人
Coplandの名残の終わり (スコア:3)
よくもまあ,HFS+を使い続けたものよ…
Re: (スコア:0)
邪悪な Oracle が邪魔しなければ、とっくの昔に ZFS に移行していたであろうにな。
Re:Coplandの名残の終わり (スコア:3)
Re:Coplandの名残の終わり (スコア:2)
# POWER8搭載XserveにOracle DBを標準添付したら売れそう
# ……冗談は置いておくとしても、MacBook AirのRAM 4GBではOpenZFS on Macつらいのは認めます
すごいな (スコア:0)
動いているコンピュータのファイルシステムを変更するのか。
環境の統一性を重視するAppleだが、ここまでやるか。
Re:すごいな (スコア:1)
動いてないコンピュータのファイルシステムを変更するほうが難しいと思うよ。
Re: (スコア:0)
うろ覚えだけど、Windows 98のFAT32コンバータだって動いているファイルシステムの変更でしょ。
ここまでやるか、って言う程の処理なのか?
リスクが高いから滅多にやらないものではあるだろうけれど。
Re:すごいな (スコア:1)
言われてみればFAT32 -> NTFSもできたね。
ただ、強制的にやるのは珍しいかも。
Re: (スコア:0)
あー、確かに強制ってのは聞いたことないね。
まあ、Appleらしさだねぇ。
MSがやったら絶対に非難囂々だなぁ。
ハードウェア環境も多岐にわたるから、失敗するマシンも出るだろうし。
Re:すごいな (スコア:2)
iOSで問題がなくても,macOSでいきなり飛びつくのはやめといた方がよさそう。
Re: (スコア:0)
iPhoneって外部からはドライブとして認識されることはないから、ということもあるよね。
Re: (スコア:0)
今のAndroidも外部からドライブとして認識されること無いんだけど。
今時外部からドライブとして認識されるスマホってあんの?
Re: (スコア:0)
> 今時外部からドライブとして認識されるスマホってあんの?
プロトコルとしてMTP/PTPではなくMSCにしているとPCからは一般的なドライブとして見える
スマホの機種によってはMSCモードでは物理的SDしかPCに見せない(内蔵ストレージはPCに見せない)ようにするなど
セキュリティを考慮した実装が追加されているものもある
Re:すごいな (スコア:2)
なので #3184557 では「今時」と書いているのでしょう。
Re:すごいな (スコア:2)
ただMSCはいったんAndroid OS側から切り離さなきゃならんので、一般ユーザーに開放するには不都合が多いと思います。
# 開発者の端くれとしてはMSCも裏コマンドで開放してほしいと思うことはしばしば。ADBじゃ面倒だしなんか遅い。
HFS+より速くなってるとか言う話だけど…… (スコア:0)
それってもしかして、ファイルシステムでのUnicode正規化をやめたから?
# ZFSが欲しかったなぁ、とは思ったもんだが、それならWatchにはリソース不足で積めないし、これでよかったのかなぁ
Re:HFS+より速くなってるとか言う話だけど…… (スコア:2)
こう考えるとNTFSなWindowsは堅牢よね。
Re:HFS+より速くなってるとか言う話だけど…… (スコア:2, すばらしい洞察)
昔のNTFSはそうでもなかった。まあ歳月はファイルシステムを変えるということだな。
Re:HFS+より速くなってるとか言う話だけど…… (スコア:2)
ジャーナリングのないHFS+はFAT以下の信頼性だったからな…
古参のマカーだったら,ファイルシステムが修復不能になった経験は,片手じゃ足りないはず。
Re:HFS+より速くなってるとか言う話だけど…… (スコア:1)
KT7.5でHFSから使ってますが、修復不能になった経験は一度もありません。
チェックで軽微なエラーはよく出てましたけど。
8.1からはHFS+もすぐ使い始めましたけど、同様に重大なエラーに遭ったことはないです。
MacOSXもPublicBetaから使ってますが、ジャーナリング無しで特に問題が出たこともないです。
(ジャーナリング機能は10.2以降(サーバ版のみ有効。一般向けはコマンドで有効化可能)、正式には10.3から)
G3Macに40GBのHDD入れて1パーティションで使ってて、Speed Diskかけたら
システムファイル?が8GBの壁を越えてしまい、うっかり起動不能になったぐらいか。
これは自業自得。
Re:HFS+より速くなってるとか言う話だけど…… (スコア:3)
よっぽど躾け方がよかったんでしょうな。
(※自分はfirstAidで修復できない状態を「修復不能」と呼称します)
まあ,ディスクが物理的に壊れたわけではないので,
無理矢理マウントしてファイルを救出する方法はいくらでもあったりするのですが。
Re:HFS+より速くなってるとか言う話だけど…… (スコア:2)
確かに「自分の」なら,適時対処して事なきを得ますけど,
「職場の」は致命的になったやつを相談受けるからねえ…
2~3ヶ月に1台はデータは(DiskWarriorで)救い出せるものの,
予防的に再フォーマットの憂き目にあっていました。
Windowsの方は,
システムが壊れたり,HDDが物理的に壊れるのはありますけど,
ファイルシステムで困った,という経験はないですよねえ…
Re: (スコア:0)
Win10をWin7を行き来してUSBが壊れるとかね
Re: (スコア:0, オフトピック)
ちゃんと切断しないやつが悪い
Re: (スコア:0)
> こう考えるとNTFSなWindowsは堅牢よね。
NTFS以上に多様なHWで荒い使われ方するFSなんてないからね。
# 強いて言うとFATか
Re: (スコア:0)
やめたという情報源はどこに?
その辺は継承のようだけど
合成除外の扱いを変えたらいいのに
Re:HFS+より速くなってるとか言う話だけど…… (スコア:1)
http://naruse.hateblo.jp/entry/2017/03/28/181519 [hateblo.jp]
Re: (スコア:0)
これだけでは分解をやめただけなのか合成するようになったのか判断が付きませんなぁ
// いやまあわざわざやることはないだろうけどさ
Re:HFS+より速くなってるとか言う話だけど…… (スコア:1)
「NFDで作ったらNFDのままだった」という記事やツイートと「NFCで作ったらNFCのままだった」という記事の両方があったので、合わせると分解をやめたと推測できる。
なんで誰も1つの記事で両方テストしていないのかは謎。
Re: (スコア:0)
HFS+から移行した場合、既存のファイル名はNFD分解したままだよね?
その場所に、NFCの同じファイル名を作成するとどうなるんだ?
Re:HFS+より速くなってるとか言う話だけど…… (スコア:2)
Re: (スコア:0)
ZFSはメモリ的に無理じゃないかなMacOSならともかくios では辛い
2014年開発開始でもう投入… (スコア:0)
投入は2018年とか聞いてたんだけど、10.3とかいう中途半端なバージョン番号でいきなり投入なんて、なにか政治的な理由で前倒しになったの?ファイルシステムのバグ取りって結構時間かかるもんじゃないのかな、btrfsの悪口言う訳じゃないけど…
Re: (スコア:0)
ユーザーに使ってもらってまさにバグ取りをしようというだけではないでしょうか。
母数多いからはかどる
Re: (スコア:0)
Mapsで [apple.srad.jp] 一騒動やらかして [apple.srad.jp]、
中の人もそういうやんちゃが引き起こす結果については懲りてるんじゃないかな。
Re: (スコア:0, 荒らし)
次のiPhoneやiPadでもうインテルx86化(+MacOSXとの実装統合)していくのでしょう
それに備えて既存のARMの端末で新FSの人柱強制(いわゆる有償ベータテスター)させつつ、
インテルx86版のiPhoneやiPadと同時ではなく先に移行させておきたいと考えるのは自然なことです
Re:2014年開発開始でもう投入… (スコア:2)
MacbookなどのCoreMレベルの代用であれば,
ARMと置き換えるかどうかは,すでにタイミングのみの問題ですよ。
伊達にUniversal Binaryをやってきたわけではないのでありますよ…
(ユーザにとっては迷惑以外の何物でもないがw)
Re:2014年開発開始でもう投入… (スコア:2)
それに,MacProが前々刷新されないんだから,
もうやる気ないんじゃね?と思われても仕方ないだろ。
Re:2014年開発開始でもう投入… (スコア:1)
次のiPhoneやiPadでもうインテルx86化(+MacOSXとの実装統合)していくのでしょう
それに備えて既存のARMの端末で新FSの人柱強制(いわゆる有償ベータテスター)させつつ、
インテルx86版のiPhoneやiPadと同時ではなく先に移行させておきたいと考えるのは自然なことです
何故、MacのARM化は想定しなかったのかw
なんかブチ抜きそうな名前っすね (スコア:0)
APFS?
APFSDS?
APDS-FS?
ワケワカメ
# オフトピでサーセン
ファイルシステムがいまいち分からん (スコア:0)
linuxやOSを勉強しているとある段階で必ずファイルシステムが出てくる、ぼんやりとは分かっているけど分からないところがある
まずファイルを物理的に読み書きするとき最終的にストレージのコントローラーが用意してる共通APIがあってそれで制御しているのかOSのAPIでコントローラに命令してるのか良く分からない
次にlinuxで扱うファイルシステムがOSのカーネルに取り込まれていなくて外部ソフトを通して読み書きする場合そのファイルシステムをlinuxがどう見てるのか分からない(ユーザーが関知するする部分ではないがOSに興味があるので調べている)
この二点ヒントだけでも教えて欲しい
Re:ファイルシステムがいまいち分からん (スコア:1)
OS「そのファイルはこのFile Systemに収められているから、そのFile System君に頼もう」というほぼ丸投げ状態(笑)
File System「OSさんの命令に従うなら、このデバイスのここにこんな情報を書けばいいな。Device Driverさんよろしく」
Device Driver「コントローラーは命令通りきりきり働け!File Systemさんが完了をお待ちだぞ!」
コントローラー「こっちだって頑張ってるんだから、お客さん待たせとけ!」
Linuxはそんな感じです(笑)。
Linuxソースを追いかけるなら、組み込み用jffs2非圧縮ファイルシステムを読むという状況のつもりで、fs/read_write.c、fs/jffs2/read.c、drivers/mtd/mtdblock.c、drivers/mtd/devices/m25p80.cという順序が易しいかな。m25p80互換のフラッシュメモリーはありふれているので、ネットで探せばマニュアルは入手できるでしょう。使い方もそんなに難しくありません。
この流れを正確に理解した若い人材ならLinux関連企業から引く手あまたですよ…と悪魔のささやき。実際紹介した3つのファイルを理解するために読まなきゃいけないソースファイルはもっとありますから(笑)。
vyama 「バグ取れワンワン」
Re: (スコア:0)
Re:ファイルシステムがいまいち分からん (スコア:3)
ドライバもカーネル空間の中だし。
Interactive map of Linux kernel [makelinux.net]とかLinuxカーネル解読室 [osdn.net]辺りは眺めが良いかな
# 「storage」のsys_open→vfs_readからlibata→ahci_pci_driverまで目で追ってみよう
Re:ファイルシステムがいまいち分からん (スコア:2)
Re:ファイルシステムがいまいち分からん (スコア:2)
いつもの(邪悪なM$(笑)ボット) (スコア:0)
もはや和ゴミと並ぶスラド名物ですな
Re:いつもの(邪悪なM$(笑)ボット) (スコア:2, すばらしい洞察)
あれは(意図的に似せてるのを除くと)ほぼ同一人物ってわかるからネタになるけど
Apple関連はいまいち「あ、あの人だ」みたいな感じがないから面白味に欠ける
Re:アクセス権が壊れるのも? (スコア:2)
かぴたんでルートレスモードが搭載され,Sierraではアクセス権の修復という項目自体がなくなった。
Re:アクセス権が壊れるのも? (スコア:2)