作者查詢 / operationcow
作者 operationcow 在 PTT [ Linux ] 看板的留言(推文), 共61則
限定看板:Linux
看板排序:
全部ToS3993PuzzleDragon1360LoL435NSwitch385Hsinchu233MiHoYo215C_Chat211SummonsBoard140SummonersWar91EuropeTravel62Linux61C_and_CPP49LinuxDev46Windows40WinNT38DIABLO36cat29sex14ToS_Match14CGSH87th32113Palmar_Drama13ASM12Programming12Badminton11Baseball11basketballTW10home-sale10BlueArchive7Web_Design7painting6WorldCup5AnimalForest4C_Sharp4FreeBSD4PlayStation4Prob_Solve4Sub_GMobile4Tech_Job4Ajax3Flash3GoodPregnan3Gossiping3Japan_Travel3MacDev3NtuDormM33OOAD3CHSH-3192Golden-Award2joke2NCHU-CE-1002NKFUST-CCE902NTU_BOTDorm22NTUcourse2NTUT_ME495A2stationery2SummerCourse2TaiwanDrama2TBBT2TFSHS68th3212Boy-Girl1CFantasy1ComGame-Plan1CompBook1e-shopping1EAseries1EE_Comment1Electronics1FuhTan1Ind-travel1jeonjihyun1L_TaiwanPlaz1Little-Games1MapleStory1Militarylife1multi-lovers1Navy1NCCU_SEED1NTU1Nurse1NUU_CSIE1Olympics_ISG1PDA1PHP1PLT1PokeMon1Ruby1Suckcomic1SuperIdol1tetris1TTV1WindFantasy1<< 收起看板(91)
1F推:你是用 Ubuntu 9.10 嗎?? 直接輸入開 gvim 會有錯誤12/22 02:13
2F→:訊息12/22 02:13
2F→:因為這樣沒有解決問題阿._., sudo apt-get 大家都會12/21 14:03
3F→:用熟練也不代表什麼12/21 14:03
7F推:好強QQ, 9.10 適用後發現變得跟XP一樣慢OTZ12/21 04:32
8F→:而且login畫面還是Ubuntu, 真不協調QQ12/21 04:32
2F→:我是看 man sshd_config 裡面的 LogLevel, 那個似乎11/28 15:17
3F→:只能設定不同的 LogLevel, 不能看到所有可能的11/28 15:17
4F→:message, 請問有什麼方式可以看到所有的 log message11/28 15:18
5F→:呢?? 感謝11/28 15:18
30F→:這是釣魚文嗎 呵呵08/18 09:39
3F→:登出前 history -w, 寫的進去嗎??07/21 05:31
4F→:http://0rz.tw/S8KIq07/21 05:35
10F→:你 ls -al ~/ | grep -i history 會顯示出??07/21 14:04
4F→:自動重灌,酷耶@@, 你打算什麼時候啟動這個 script ??07/19 18:18
4F→:實際資料所佔區塊07/19 17:15
5F→:所以應該兩個都要磁碟重組不是嗎?07/19 17:16
6F→:不過我記得 Tanenbaum 有一篇 paper 提到檔案大小大07/19 17:19
7F→:概是 1K(1 個 block), 這樣來看的話說不定 Linux 用07/19 17:20
8F→:inode 的方式反倒比較需要磁碟讀取, 這樣應該是 FAT07/19 17:22
9F→:比較吃香, inode 可以用 caching 和 磁碟重整 inode07/19 17:22
10F→:來獲得加速07/19 17:22
11F→:補充一下,上面提到的 paper 是 Mullender and07/19 17:23
12F→:Tanenbaum 在 1984 提出的, 對象是 Unix, 現在看可能07/19 17:23
13F→:有一點不合時宜, 剛剛打開我的資料夾,檔案多是幾十 k07/19 17:24
14F→:到幾百 k, 不過如果從文章中的分析, 應該是兩個都需07/19 17:25
15F→:要磁碟重整??07/19 17:25
18F→:整個"檔案配置表"不可能比整個"資料所佔區塊"來的大07/19 17:42
19F→:這樣使用太沒效率了07/19 17:43
20F→:以一個20GB大的硬碟來說, 1kB/block, 大概是使用80MB07/19 17:45
21F→:的記憶體作為 FAT07/19 17:45
27F→:所以版主的意思是說鳥哥及某些文章所說的, 索引式檔07/20 08:36
28F→:案系統比較不需要磁碟重組是錯的, 問題是出在寫入資07/20 08:37
29F→:料的演算法??07/20 08:37
30F→:另外就是採用 block 使得資料在 physical view 產生07/20 08:38
31F→:不連續的現象似乎不叫 fragmentation??07/20 08:38
32F→:fragmentation 該是分 internal 和 external, 而07/20 08:39
33F→:internal 應該是跟 block 的大小與檔案的大小有關,07/20 08:39
34F→:external 在 block 的機制下應該是避掉了07/20 08:41
35F→:抱歉, 修正一下上面所說, 這種採用 block 而資料不連07/20 08:42
36F→:續的現象應該算是 data fragmentation07/20 08:42
37F→:http://0rz.tw/JYz6C07/20 08:43
38F→:不過針對寫入資料的演算法那部份, 我提出質疑07/20 08:44
39F→:因為在最原始的 Linux/Minix file system, 是採用07/20 08:44
40F→:zone 的方式來使得資料存在硬碟的同一個 cylinder07/20 08:46
41F→:可是在 http://0rz.tw/jzG8y An Improvement for07/20 08:47
42F→:MINIX File System:Design and Implementation 這篇07/20 08:48
43F→:文章中提到, there is no implied relationship07/20 08:49
44F→:between logical sector addresses and the actual07/20 08:49
45F→:physical location of the data sector07/20 08:49
46F→:因為都被 drive controller 給最佳化/隱藏掉了07/20 08:50
47F→:因此不是想寫哪邊就寫哪邊, 不太可能是因為寫入演算07/20 08:51
48F→:法的不同造成磁碟重組與否 @@07/20 08:52
1F→:剛剛試驗, od 也無法辦到 OTZ...07/18 00:37
2F→:http://ppt.cc/KZPr07/06 19:12
3F→:可以說說使用 Wubi 的錯誤訊息嗎??07/06 19:14