Re: [請益] 關於SD卡健康度檢測軟體以及Finaldata

看板Storage_Zone (儲存裝置)作者 (釣到一隻猴子@_@)時間12年前 (2013/11/30 16:41), 編輯推噓2(2046)
留言48則, 2人參與, 最新討論串2/2 (看更多)
※ 引述《joulin (joulin)》之銘言: : 你都說長了 我就吃光光了XD 先來個基本概念 這篇Finaldata上的磁簇是指在邏輯磁簇上的位置 實際上的位置軟體基本上也管不著 檔案系統 (應該是FAT32 邏輯空間 (這邊這個是邏輯的 是軟體知道的狀況 非實體狀況 實際儲存 (這裡才是實際狀況 由韌體負責 上面是儲存設備的各層 : 我直接整理出我想要問的問題~ : 1.我知道硬碟有磁區的先後,是按照其在磁盤上的位置排列, : 那記憶卡是否有磁區的先後編號? 當然有 記憶卡內的BLOCK也是分布在不同位置 不過不像硬碟是環狀排列 而是成矩陣 : 2.我現在理解到Finaldata那個磁簇是邏輯上的, : 所以有跳過磁簇並不代表記憶卡壞掉很多磁區, : 他所賦予的磁簇編號,也不是實體磁區的編號, : 可是,既然不是,那為什麼如果只把某檔案刪掉, : 在寫入新的檔案,該新的檔案的編號會去填補原本被刪掉的檔案的編號呢? 把最上面那個分層拿回來 當你放了新檔案後 檔案系統會決定該放在邏輯空間的哪部分 而FAT32的原則是前面有足夠空間能塞就塞(完整為前提) 不夠就往最後面放 最後面也不夠才拆開到處塞 : (當然,刪掉檔案跟新的檔案因為大小不同,所以所佔用的磁簇多寡一定不同, : 這就會導致被刪掉的那個檔案的那些磁簇編號,在被新的檔案使用之後, : 還會剩下一些編號,所以這些磁簇編號就會看起來像是被跳過了) : 而且,Finaldata軟體的運算機制到底是怎麼樣? 為什麼有時會跳過某些磁簇? Finaldata只是把實際狀況列出來 這部分怎放跟他無關 這是FAT32檔案系統決定的 : 然後為什麼大部份情況都是按照檔案寫入時間去排列, : 可是卻有時會發生順序不對的問題? : 有沒有專業大大瞭解~ 當你沒刪檔案 或者刪了就全刪 自然始終都是很大塊的連續空白空間 照上面的原則 這部分就很理所當然了 : 3.記憶卡有硬碟一樣自動屏蔽壞損磁區的功能嗎? 當然 而且FLASH更需要這樣做 HDD的磁區損壞是可能發生 FLASH的損壞是絕對會發生 (雖然這樣說也不太對啦XD) : 4.硬碟有很多軟體可以去監測他的健康程度, : 在他可能壞損之前做處理或備份或者決定不再使用, : 有沒有記憶卡專用的健康度掃描軟體,感覺知道記憶卡健康程度還蠻重要的, : 不然要是出國玩個幾天,回來才發現記憶卡壞了,真的會很心碎的.... 兩個字 沒有! SSD都已經是備份、備份再備份 祈禱他真的會乖乖撐到壽命到了才掛 你認為記憶卡有可能更好嗎? FLASH這東西是說掛就掛的 沒任何徵兆 並不像HDD壞掉前可能會有些不良狀況 : 以上,問題有點多,希望有經驗或是瞭解情況的大大們可以給予一些解答~ : 小弟感激不敬!!! : 當然就算沒有相關經驗也都可以一起參與討論喔~ : 讓彼此更瞭解記憶卡的運作, : 恩,知己知彼才能百戰百勝麻(誤) : 不是拉,是知道之後,才可以更避免資料消失的窘境XD : 畢竟記憶卡又不能像硬碟一樣,即時備份@@,(邊拍邊備份) : 要是途中壞了,真的可能是一去不復返 : PS.我知道有些相機是雙插卡的,而且好像可以將同一個檔案寫入兩張卡, : 以防記憶卡壞掉,不過畢竟這種相機實在是太高檔太貴了,不太適合大眾使用 : 所以,還是瞭解記憶卡健康程度比較實際..... 順便回一下前面那長串裡說的平均抹寫 簡單來說~~~ 再把前面分層拿回來 你實際上軟體最多能知道的只有邏輯空間那塊 最底下的實際儲存只有韌體才會知道 所以可能你邏輯空間是很整齊有順序從1 2 3 4 5這樣排列 實際上在FLASH裡可能是84 55 31 15 67之類這樣亂塞的 這部分HDD其實也一樣 只是HDD多數時候邏輯和實體是對應的 只有當有地方出現損壞搬出備用區塊時才會發生不一致的情況 但FLASH設備為了平均抹寫就這樣做了 反正FLASH也沒隨機存取效率低落的問題XD -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.216.102

11/30 18:21, , 1F
感謝大大專業的回復!!!真是懂了不少!!!
11/30 18:21, 1F

11/30 18:21, , 2F
另外有一個問題請問,所以為何會發生我這次的情況
11/30 18:21, 2F

11/30 18:22, , 3F
就是我原文中提到的7906的檔案 會被寫到最後邏輯區去
11/30 18:22, 3F

11/30 18:22, , 4F
可是在那當下 前面的邏輯磁簇還有空間啊@@
11/30 18:22, 4F

11/30 18:23, , 5F
然後7907又寫回前面的磁簇去...... 後來大概是因為
11/30 18:23, 5F

11/30 18:23, , 6F
發現前面有一個空間 所以8014又跑去存在前面空下的
11/30 18:23, 6F

11/30 18:24, , 7F
那個磁簇了? 可是為何會發生7906跳到最後的情況呢
11/30 18:24, 7F

11/30 20:14, , 8F
你確定那前面的空間 夠塞進那個新檔案?(保持連續)
11/30 20:14, 8F

11/30 20:15, , 9F
FAT32的寫入原則是不產生碎片前提下盡量往前塞
11/30 20:15, 9F

12/01 01:19, , 10F
我是一張新卡完全沒有寫入任何東西的
12/01 01:19, 10F

12/01 01:20, , 11F
相機拍照的編號會一直往下跳 寫入到7905時 後面
12/01 01:20, 11F

12/01 01:20, , 12F
的磁區並沒有任何檔案 所以應該繼續按順序寫入
12/01 01:20, 12F

12/01 01:21, , 13F
所以7906理應排在7905的磁簇後面? 可是結果卻
12/01 01:21, 13F

12/01 01:22, , 14F
不是@@ 我整張記憶卡沒有刪過任何檔案~
12/01 01:22, 14F

12/01 01:24, , 15F
而且 7907有繼續寫在7905 表示7905後面確實有一大片
12/01 01:24, 15F

12/01 01:24, , 16F
空白的地方 所以理應沒有往後塞的道理?
12/01 01:24, 16F

12/01 01:24, , 17F
為了清楚一點 我把各檔案的磁簇寫出來好了
12/01 01:24, 17F

12/01 01:29, , 18F
7905 所在磁簇 952395 ~ 952552
12/01 01:29, 18F

12/01 01:30, , 19F
8014 所在磁簇 952553 ~952747
12/01 01:30, 19F

12/01 01:31, , 20F
7907 所在磁簇 952758 ~ 952967
12/01 01:31, 20F

12/01 01:32, , 21F
7908 所在磁簇 952968 ~ 953185
12/01 01:32, 21F

12/01 01:32, , 22F
7909 所在磁簇 953186~953392
12/01 01:32, 22F

12/01 01:33, , 23F
後面略 一直到最後
12/01 01:33, 23F

12/01 01:33, , 24F
8013 所在磁簇 972161~972341
12/01 01:33, 24F

12/01 01:34, , 25F
7906 所在磁簇 972539~ 972744
12/01 01:34, 25F

12/01 01:35, , 26F
可以看到所有檔案都是一個磁簇接著一個 不曾斷過
12/01 01:35, 26F

12/01 01:35, , 27F
除了952553~ 952757 這204個磁簇 本應該填入7906的
12/01 01:35, 27F

12/01 01:36, , 28F
可是卻變成很後面才寫入的8014那張照片了
12/01 01:36, 28F

12/01 01:36, , 29F
值得一提的是 7906 佔的空間 好像是205個磁簇
12/01 01:36, 29F

12/01 01:36, , 30F
跟204有點接近 所以應該是原本有寫入在那裡?後來
12/01 01:36, 30F

12/01 01:37, , 31F
被移到後面? 可是 怎麼會所佔磁簇差了1呢?@@
12/01 01:37, 31F

12/01 01:37, , 32F
另外一個線索 我在所謂的遺失檔案中 找到了一張
12/01 01:37, 32F

12/01 01:38, , 33F
跟8014一模一樣的檔案 它所佔的磁簇是
12/01 01:38, 33F

12/01 01:39, , 34F
972342~972536 不但檔案內容(我說的是在finaldata
12/01 01:39, 34F

12/01 01:40, , 35F
中右鍵選檢視檔案看到的東西 就是一堆看似亂碼的東西
12/01 01:40, 35F

12/01 01:40, , 36F
其實那應該就是檔案真實內容吧?) 相同 所佔磁簇
12/01 01:40, 36F

12/01 01:41, , 37F
為194 與952553~952747同樣都是佔194 可以判斷是
12/01 01:41, 37F

12/01 01:42, , 38F
同一個檔案 我猜想 應該是被檔案系統搬到前方去
12/01 01:42, 38F

12/01 01:42, , 39F
然後把後面那個972342~972536的資料清除了 所以
12/01 01:42, 39F

12/01 01:43, , 40F
才會跑到“遺失檔案”去~ 至於
12/01 01:43, 40F

12/01 01:43, , 41F
為何檔案系統要把7906那個檔案搬到最後面去
12/01 01:43, 41F

12/01 01:44, , 42F
然後又把8014那個檔案搬去前面我真的不太懂為什麼@@
12/01 01:44, 42F

12/01 01:45, , 43F
另外還有一個M0100.CTG檔 這應該是canon相機對照片
12/01 01:45, 43F

12/01 01:47, , 44F
製作的索引檔案 他位在952748~952749
12/01 01:47, 44F

12/01 01:47, , 45F
也就是也處在那個照片7905與7907中間空下的磁簇中
12/01 01:47, 45F

12/01 06:56, , 46F
這部分要問你的相機做過啥操作了XD
12/01 06:56, 46F

12/01 06:57, , 47F
總之這邊說的是原則 實際上也要看設備怎處理
12/01 06:57, 47F

12/01 06:58, , 48F
畢竟相機裡應該不是用M$寫的那套library
12/01 06:58, 48F
文章代碼(AID): #1IcQJKzB (Storage_Zone)
文章代碼(AID): #1IcQJKzB (Storage_Zone)