[過去ﾛｸﾞ] マカーによるWindows機の受け入れられないところ (1002ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
624(1): 2019/06/27(木)18:53 ID:IpD32p3E0(2/3) AAS
>>620
これ、HDDでもやってるのかな。
実際にやったら一瞬で断片化しまくって
酷い事になると思うけど。
625: 2019/06/27(木)19:00 ID:IpD32p3E0(3/3) AAS
>>623
Win10触ったこと無いけど、再開機能はなかったのか。
626: 2019/06/27(木)19:25 ID:Hmf0ttKg0(2/3) AAS
>>620
HDDでもとかそういう話じゃなくて、そういう動作をするからSSDに優しいじゃんって話なのでは？
627: 2019/06/27(木)19:26 ID:Hmf0ttKg0(3/3) AAS
>>624
逆に断片化しないのでは？
データの実態が動くわけじゃないんだから
628: 2019/06/27(木)19:26 ID:oyjSluaH0(2/5) AAS
>>622
寿命は兎も角、パフォーマンスは解決出来てなくね？
629: 2019/06/27(木)20:00 ID:TAb3tkhG0(2/2) AAS
>>620
差分になるからHDDに向かないんだろ
630: 2019/06/27(木)20:46 ID:bFedGrPt0(1/3) AAS
変更を差分で取るなら断片化するだろうね
でも、これコピーしないと意味ないでしょ？
コピー&部分的な修正 でのみ意味がある。
ファイルを開いて別名保存というのはコピーじゃないから意味がない
アプリ側の対応も必要だろうね。
効果があるのは大きなファイルの一部分を変える時だけ
おそらくサイズが変更した場合とかは対応できないよ
631(1): 2019/06/27(木)21:17 ID:oyjSluaH0(3/5) AAS
アプリの対応なんか要らんよ。
例えば仮想環境のイメージ複製してから実行すると、書き込んだ内容は差分扱いになるんじゃないかな。
632(1): 2019/06/27(木)21:40 ID:oyjSluaH0(4/5) AAS
実際今やってみた。
15GB程度の仮想Ubuntu環境だけど、
領域の複製は当然一瞬で終わるし、複写元合わせて2つの領域をそれぞれ並行で実行して
片方には適当に追加でファイル保存させたりしたけど、
特別大きな書き込みも待ち時間も発生せずサクサク動作してた。
複製前、SSD(APFS)において995.36GB使用済みだったとして、
上記の作業後は995.96GB使用済みとなった。
少なくとも元の領域分15GBまるまる増えたりはしていないのは確認できた。
633: 2019/06/27(木)23:14 ID:bFedGrPt0(2/3) AAS
>>631
> 例えば仮想環境のイメージ複製してから実行すると、書き込んだ内容は差分扱いになるんじゃないかな。
仮想マシンの場合、イメージが数GB単位と大きくて
小さな変更がこまめに入るからね。
1. 仮想マシンのイメージを作る
2. 仮想マシンのイメージのコピーを作る（何のため？）
3. 仮想マシンのイメージのコピーを修正する → 差分で保存される。
1の仮想マシンのイメージと3の仮想マシンのイメージ、
2つの仮想マシンのイメージファイルは、一部のデータを共有している。
所で、仮想マシン以外でファイルを複製してほんの
省1
634(1): 2019/06/27(木)23:18 ID:bFedGrPt0(3/3) AAS
>>632
全く同じ内容ならそうだろう。
気になるのは、
1. 1バイトだけ変更した時どうなるか？
2. 1バイトファイルの頭に付け加えた時どうなるか？
3. 既存のアプリで開いて内容を変えずに保存した場合どうなるか？
特に気になるのは3だな。仮想マシンのようにファイルの一部を変更するのではなく
ファイルを読み込んでメモリに入れた後、メモリの内容を書き出すといった処理をしている場合に
果たしてファイルは共有されるのだろうか？
635(1): 2019/06/27(木)23:44 ID:oyjSluaH0(5/5) AAS
>>634
1、2は差分。
3はアプリの仕様次第なのでは。
画像やドキュメント系の比較的小さなファイル扱うアプリだと新規扱いになるのかな。
ファイルメーカーとかライブラリ(データベース等)管理的なアプリだと差分になりそう。
扱うデータがデカけりゃデカい程、アプリのパフォーマンス的にも毎回全データ書き直しは現実的じゃないだろうしね。
636(1): 2019/06/28(金)00:05 ID:uxV8/Ll+0(1/5) AAS
画面で何か変更加えたらその部分を即ストレージに反映(保存)するタイプだと複製と差分が活きるんじゃないかね。
例えばWindowsだとAccessのMDBファイルなんか割と複製でバックアップ取りながら作業するじゃん？
637(1): 2019/06/28(金)03:57 ID:wg3i7DLF0(1/2) AAS
>>635
差分になるのは、オリジナルとクローン、最低でも２つのファイルが有る場合のみだよね？
638(1): 2019/06/28(金)03:58 ID:wg3i7DLF0(2/2) AAS
>>636
コピーしてバックアップを取って書き換えるってことはしないな
639(1): 2019/06/28(金)04:39 ID:eqhIshiK0(1) AAS
>>637
何を言っとるんだお前は
640(1): 2019/06/28(金)07:31 ID:g2xK75gW0(1) AAS
>>639
意外と応用範囲が広くないってことだよ。
ファイルを書き換える時に、一部分のみを書き換えるってのがあまりないし、
稀な例として仮想マシンのイメージやデータベースが有るけれど、
それらだって前のファイルを残しつつ、一部分を書き換えるってことはあまりしない。
バックアップで使えるかもしれないが、バックアップは物理的に異なるディスクに
保存しなければいけないから差分は使えない
スナップショットの代わりとして使えるが、でもそれならスナップショットでいいやん？
NTFSはスナップショットをサポートしてる。
641: 2019/06/28(金)09:06 ID:xxLotuch0(1/4) AAS
>>640
どんなアプリがどこでどんなファイル処理してるかなんてそのアプリのデベロッパーでもなければわからん。
その辺のファイルの挙動なんて一般的にはユーザーが気にする部分じゃないし、
常にストレージ消費を監視してるような特殊な趣味でもなければ
自身では気づいてなくても普段使ってる上で割と恩恵にあずかってるかもしれんぞ。
642(1): 2019/06/28(金)09:37 ID:xxLotuch0(2/4) AAS
今職場だが暇なのでまた試してみた。
今度は一般的な単一ドキュメントファイルを扱うKeynote(OfficeにおけるPowerPointみたいなもの)で。
ちなみにファイルタイプはパッケージ形式じゃなく
ちゃんとシングルファイル形式にしたから安心してくれ。
Keynoteファイルを新規作成して適当な動画ファイルを埋め込んで保存したところ、
まず130MB程のファイル(テスト.key)がAPFS上に作成された。
この時点でストレージのトータル使用領域は787.48GB(787,476,611,072バイト)。
ここで先のファイルを複製。
Keynoteで開いて適当に編集(テキストエリアを追加)して保存。
この新しいファイル(テストのコピー.key)も130MB程度のファイルサイズだが、
省6
643(1): 2019/06/28(金)09:57 ID:xxLotuch0(3/4) AAS
macOSのNSDocumentクラスとか使ってるアプリだと上手くやってくれるのかもしれんね。
ちなみに先にFinderで複製するのではなく、
一旦開いたファイル(テストのコピー2.key[130MB])を
Keynoteのファイルメニューから「複製」選んで1MB程度の画像ファイルを貼り付けて
保存(テストのコピー3.key[131MB])した場合は、トータル使用領域は7MBぐらいしか増えなかった。
上下前次1-新書関写板覧索設栞歴
あと 359 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.014s