0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

Linux系統(tǒng)文件讀寫流程

Linux閱碼場 ? 來源: Linux閱碼場 ? 2023-11-05 09:29 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

前言

網(wǎng)上關(guān)于BIO和塊設(shè)備讀寫流程的文章何止千萬,但是能夠讓你徹底讀懂讀明白的文章實(shí)在難找,可以說是越讀越糊涂!

我曾經(jīng)跨過山和大海 也穿過人山人海

我曾經(jīng)問遍整個世界 從來沒得到答案

本文用一個最簡單的read(fd, buf, 4096)的代碼,分析它從開始讀到讀結(jié)束,在整個Linux系統(tǒng)里面波瀾壯闊的一生。本文涉及到的代碼如下:

#include

#include

main()

{

int fd;

char buf[4096];

sleep(30); //run ./funtion.sh to trace vfs_read of this process

fd = open("file", O_RDONLY);

read(fd, buf, 4096);

read(fd, buf, 4096);

}

本文的寫作宗旨是:絕不裝逼,一定要簡單,簡單,再簡單!

本文適合:已經(jīng)讀了很多亂七八糟的block資料,但是沒打通脈絡(luò)的讀者;

本文不適合:完全不知道block子系統(tǒng)是什么的讀者,和完全知道block子系統(tǒng)是什么的讀者

Page cache與預(yù)讀

在Linux中,內(nèi)存充當(dāng)硬盤的page cache,所以,每次讀的時候,會先check你讀的那一部分硬盤文件數(shù)據(jù)是否在內(nèi)存命中,如果沒有命中,才會去硬盤;如果已經(jīng)命中了,就直接從內(nèi)存里面讀出來。如果是寫的話,應(yīng)用如果是以非SYNC方式寫的話,寫的數(shù)據(jù)也只是進(jìn)內(nèi)存,然后由內(nèi)核幫忙在適當(dāng)?shù)臅r機(jī)writeback進(jìn)硬盤。

521f8cea-7b6f-11ee-939d-92fbcf53809c.png

代碼中有2行read(fd, buf, 4096),第1行read(fd, buf, 4096)發(fā)生的時候,顯然”file”文件中的數(shù)據(jù)都不在內(nèi)存,這個時候,要執(zhí)行真正的硬盤讀,app只想讀4096個字節(jié)(一頁),但是內(nèi)核不會只是讀一頁,而是要多讀,提前讀,把用戶現(xiàn)在不讀的也先讀,因?yàn)閮?nèi)核懷疑你讀了一頁,接著要連續(xù)讀,懷疑你想讀后面的。與其等你發(fā)指令,不如提前先斬后奏(存儲介質(zhì)執(zhí)行大塊讀比多個小塊讀要快),這個時候,它會執(zhí)行預(yù)讀,直接比如讀4頁,這樣當(dāng)你后面接著讀第2-4頁的硬盤數(shù)據(jù)的時候,其實(shí)是直接命中了。

所以這個代碼路徑現(xiàn)在是 :

5230ec38-7b6f-11ee-939d-92fbcf53809c.png

當(dāng)你執(zhí)行完第一個read(fd, buf, 4096)后,”file”文件的0~16KB都進(jìn)入了pagecache,同時內(nèi)核會給第2頁標(biāo)識一個PageReadahead標(biāo)記,意思就是如果app接著讀第2頁,就可以預(yù)判app在做順序讀,這樣我們在app讀第2頁的時候,內(nèi)核可以進(jìn)一步異步預(yù)讀。

第一個read(fd,buf, 4096)之前,page cache命中情況(都不命中):

523fd4a0-7b6f-11ee-939d-92fbcf53809c.png

第一個read(fd,buf, 4096)之后,page cache命中情況:

524ddb04-7b6f-11ee-939d-92fbcf53809c.png

我們緊接著又碰到第二個read(fd, buf, 4096),它要讀硬盤文件的第2頁內(nèi)容,這個時候,第2頁是page cache命中的,這一次的讀,由于第2頁有PageReadahead標(biāo)記,讓內(nèi)核覺得app就是在順序讀文件,內(nèi)核會執(zhí)行更加激進(jìn)的異步預(yù)讀,比如讀文件的第16KB~48KB。

所以第二個read(fd,buf, 4096)的代碼路徑現(xiàn)在是 :

5254bdac-7b6f-11ee-939d-92fbcf53809c.png

第二個read(fd,buf, 4096)之前,page cache命中情況:

52671966-7b6f-11ee-939d-92fbcf53809c.png

第二個read(fd,buf, 4096)之后,page cache命中情況:

5276b984-7b6f-11ee-939d-92fbcf53809c.png

內(nèi)存到硬盤的轉(zhuǎn)換

剛才我們提到,第一次的read(fd, buf, 4096),變成了讀硬盤里面的16KB數(shù)據(jù),到內(nèi)存的4個頁面(對應(yīng)硬盤里面文件數(shù)據(jù)的第0~16KB)。但是我們還是不知道,硬盤里面文件數(shù)據(jù)的第0~16KB在硬盤的哪些位置?我們必須把內(nèi)存的頁,轉(zhuǎn)化為硬盤里面真實(shí)要讀的位置。

在Linux里面,用于描述硬盤里面要真實(shí)操作的位置與page cache的頁映射關(guān)系的數(shù)據(jù)結(jié)構(gòu)是bio。相信大家已經(jīng)見到bio一萬次了,但是就是和真實(shí)的案例對不上。

bio的定義如下(include/linux/blk_types.h):

struct bio_vec {

struct page *bv_page;

unsigned int bv_len;

unsigned int bv_offset;

};

struct bio {

struct bio *bi_next; /* request queue link */

struct block_device *bi_bdev;

struct bvec_iter bi_iter;

/* Number of segments in this BIO after

* physical address coalescing is performed.

*/

unsigned int bi_phys_segments;

bio_end_io_t *bi_end_io;

void *bi_private;

unsigned short bi_vcnt; /* how many bio_vec's */

atomic_t bi_cnt; /* pin count */

struct bio_vec *bi_io_vec; /* the actual vec list */

};

它是一個描述硬盤里面的位置與page cache的頁對應(yīng)關(guān)系的數(shù)據(jù)結(jié)構(gòu),每個bio對應(yīng)的硬盤里面一塊連續(xù)的位置,每一塊硬盤里面連續(xù)的位置,可能對應(yīng)著page cache的多頁,或者一頁,所以它里面會有一個bio_vec *bi_io_vec的表。

我們現(xiàn)在假設(shè)2種情況

第1種情況是page_cache_sync_readahead()要讀的0~16KB數(shù)據(jù),在硬盤里面正好是順序排列的(是否順序排列,要查文件系統(tǒng),如ext3、ext4),Linux會為這一次4頁的讀,分配1個bio就足夠了,并且讓這個bio里面分配4個bi_io_vec,指向4個不同的內(nèi)存頁:

5281f1fa-7b6f-11ee-939d-92fbcf53809c.png

第2種情況是page_cache_sync_readahead()要讀的0~16KB數(shù)據(jù),在硬盤里面正好是完全不連續(xù)的4塊 (是否順序排列,要查文件系統(tǒng),如ext3、ext4),Linux會為這一次4頁的讀,分配4個bio,并且讓這4個bio里面,每個分配1個bi_io_vec,指向4個不同的內(nèi)存頁面:

528c7f58-7b6f-11ee-939d-92fbcf53809c.png

當(dāng)然你還可以有第3種情況,比如0~8KB在硬盤里面連續(xù),8~16KB不連續(xù),那可以是這樣的:

529e686c-7b6f-11ee-939d-92fbcf53809c.png

其他的情況請類似推理…完成這項(xiàng)工作的史詩級的代碼就是mpage_readpages()。

52b5a658-7b6f-11ee-939d-92fbcf53809c.png

mpage_readpages()會間接調(diào)用ext4_get_block(),真的搞清楚0~16KB的數(shù)據(jù),在硬盤里面的擺列位置,并依據(jù)這個信息,轉(zhuǎn)化出來一個個的bio。

bio和request的三進(jìn)三出

人生,說到最后,簡單得只有生死兩個字。但由于有了命運(yùn)的浮沉,由于有了人世的冷暖,簡單的過程才變得跌宕起伏,紛繁復(fù)雜。小平三落三起,最終建立了不朽的功勛。曼德拉受非人待遇在監(jiān)獄服刑數(shù)十年,終成世界公認(rèn)的領(lǐng)袖。走向自由之路不會平坦,斗爭就是生活。與天斗,其樂無窮;與地斗,其樂無窮;與Linux斗,痛苦無窮!

bio產(chǎn)生后,到最終的完成,同樣經(jīng)歷了三進(jìn)三出的隊(duì)列,這個過程的艱辛和痛苦,讓人欲罷不能,欲說還休,求生不得求死不能。

這三步是:

1.原地蓄勢

把bio轉(zhuǎn)化為request,把request放入進(jìn)程本地的plug隊(duì)列;蓄勢多個request后,再進(jìn)行泄洪。

2.電梯排序

進(jìn)程本地的plug隊(duì)列的request進(jìn)入到電梯,進(jìn)行再次的合并、排序,執(zhí)行QoS的排隊(duì),之后按照QoS的結(jié)果,分發(fā)給塊設(shè)備驅(qū)動。電梯內(nèi)部的實(shí)現(xiàn),可以有各種各樣的隊(duì)列。

3.分發(fā)執(zhí)行

電梯分發(fā)的request,被設(shè)備驅(qū)動的request_fn()挨個取出來,派發(fā)真正的硬件讀寫命令到硬盤。這個分發(fā)的隊(duì)列,一般就是我們在塊設(shè)備驅(qū)動里面見到的request_queue了。

52c2ebec-7b6f-11ee-939d-92fbcf53809c.jpg

下面我們再一一呈現(xiàn),這三進(jìn)三出。

原地蓄勢

在Linux中,每個task_struct(對應(yīng)一個進(jìn)程,或輕量級進(jìn)程——線程),會有一個plug的list。什么叫plug呢?類似于葛洲壩和三峽,先蓄水,當(dāng)app需要發(fā)多個bio請求的時候,比較好的辦法是先蓄勢,而不是一個個單獨(dú)發(fā)給最終的硬盤。

這個類似你現(xiàn)在有10個老師,這10個老師開學(xué)的時候都接受學(xué)生報(bào)名。然后有一個大的學(xué)生隊(duì)列,如果每個老師有一個學(xué)生報(bào)名的時候,都訪問這個唯一的學(xué)生隊(duì)列,那么這個隊(duì)列的操作會變成一個重要的鎖瓶頸:

52d08126-7b6f-11ee-939d-92fbcf53809c.jpg

如果我們換一個方法,讓每個老師有學(xué)生報(bào)名的時候,每天的報(bào)名的學(xué)生掛在老師自己的隊(duì)列上面,老師的隊(duì)列上面掛了很多學(xué)生后,一天之后再泄洪,掛到最終的學(xué)生隊(duì)列,則可以避免這個問題,最終小隊(duì)列融合進(jìn)大隊(duì)列的時候控制住時序就好。

52ec69a4-7b6f-11ee-939d-92fbcf53809c.jpg

你會發(fā)現(xiàn),代碼路徑是這樣的:

52fa6c16-7b6f-11ee-939d-92fbcf53809c.png

read_pages()函數(shù)先把閘門拉上,然后發(fā)起一系列bio后,再通過blk_finish_plug()的調(diào)用來泄洪。

53077014-7b6f-11ee-939d-92fbcf53809c.jpg

在這個蓄勢的過程中,還要完成一項(xiàng)重要的工作,就是make request(造請求)。這個完成“造請求”的史詩級的函數(shù),一般是void blk_queue_bio(struct request_queue *q, struct bio *bio),位于block/blk-core.c。

它會嘗試把bio合并進(jìn)入一個進(jìn)程本地plug list里面的一個request,如果無法合并,則造一個新的request。request里面包含一個bio的list,這個list的bio對應(yīng)的硬盤位置,最終在硬盤上是連續(xù)存放的。

下面我們假設(shè)"file"的第0~16KB在硬盤的存放位置為:

531526fa-7b6f-11ee-939d-92fbcf53809c.png

根據(jù)我們前面"內(nèi)存到硬盤的轉(zhuǎn)換"一節(jié)舉的例子,這屬于在硬盤里面完全不連續(xù)的"情況2",于是這4塊數(shù)據(jù),會被史詩級的mpage_readpages()轉(zhuǎn)化為4個bio。

5322882c-7b6f-11ee-939d-92fbcf53809c.png

當(dāng)他們進(jìn)入進(jìn)程本地的plug list的時候,由于最開始plug list為空,100顯然無法與誰合并,這樣形成一個新的request0。

Bio1也無法合并進(jìn)request0,于是得到新的request1。

Bio2正好可以合并進(jìn)request1,于是Bio1合并進(jìn)request1。

Bio3對應(yīng)硬盤的200塊,無法合并,于是得到新的request2。

現(xiàn)在進(jìn)程本地plug list上的request排列如下:

532ce538-7b6f-11ee-939d-92fbcf53809c.png

泄洪的時候,進(jìn)程本地的plug list的request,會通過調(diào)用elevator調(diào)度算法的elevator_add_req_fn() callback函數(shù),被加入電梯的隊(duì)列。

電梯排序

當(dāng)各個進(jìn)程本地的plug list里面的request被泄洪,以排山倒海之勢進(jìn)入的,不是最終的設(shè)備驅(qū)動(不會直接被拍死在沙灘上的),而是一個電梯排隊(duì)算法,進(jìn)行再一次的排隊(duì)。這個電梯調(diào)度,其實(shí)目的3個:

進(jìn)一步的合并request

把request對硬盤的訪問變得順序化

執(zhí)行QoS

電梯的內(nèi)部實(shí)現(xiàn)可以非常靈活,但是入口是elevator_add_req_fn(),出口是elevator_dispatch_fn()。

533b6bd0-7b6f-11ee-939d-92fbcf53809c.jpg

合并和排序都好理解,下面我們重點(diǎn)解釋QoS(服務(wù)質(zhì)量)。想象你家里的寬帶,有迅雷,有在線電影,有機(jī)頂盒看電視。

當(dāng)你只用迅雷下電影的時候,你當(dāng)然可以全速的下電影,但是當(dāng)你還看電視,在線看電影,這個時候,你可能會對迅雷限流,以保證相關(guān)電視盒電影的服務(wù)質(zhì)量。

電梯調(diào)度里面也執(zhí)行同樣的邏輯,比如CFQ調(diào)度算法,可以根據(jù)進(jìn)程的ionice,調(diào)整不同進(jìn)程訪問硬盤的時候的優(yōu)先級。比如,如下2個優(yōu)先級不同的dd

# ionice-c 2 -n 0 cat /dev/sda > /dev/null&

# ionice -c 2 -n 7 cat /dev/sda >/dev/null&

最終訪問硬盤的速度是不一樣的,一個371M,一個只有72M。

5344e89a-7b6f-11ee-939d-92fbcf53809c.jpg

所以當(dāng)泄洪開始,漫江碧透,百舸爭流,誰能到中流擊水,浪遏飛舟?QoS是一個關(guān)于一將功成萬骨枯的故事。

目前常用的IO電梯調(diào)度算法有:cfq, noop, deadline。詳細(xì)的區(qū)別不是本文的重點(diǎn),建議閱讀《劉正元:Linux 通用塊層之DeadLine IO調(diào)度器》從了解deadline的實(shí)現(xiàn)開始。

分發(fā)執(zhí)行

到了最后要交差的時刻了,設(shè)備驅(qū)動的request_fn()通過調(diào)用電梯調(diào)度算法的elevator_dispatch_fn()取出經(jīng)過QoS排序后的request并發(fā)命令給最終的存儲設(shè)備執(zhí)行I/O動作。

static void xxx_request_fn(struct request_queue *q)

{

struct request *req;

struct bio *bio;

while ((req = blk_peek_request(q)) != NULL) {

struct xxx_disk_dev *dev = req->rq_disk->private_data;

if (req->cmd_type != REQ_TYPE_FS) {

printk (KERN_NOTICE "Skip non-fs request ");

blk_start_request(req);

__blk_end_request_all(req, -EIO);

continue;

}

blk_start_request(req);

__rq_for_each_bio(bio, req)

xxx_xfer_bio(dev, bio);

}

}

request_fn()只是派發(fā)讀寫事件和命令,最終的完成一般是在另外一個上下文,而不是發(fā)起IO的進(jìn)程。request處理完成后,探知到IO完成的上下文會以blk_end_request()的形式,通知等待IO請求完成的本進(jìn)程。主動發(fā)起IO的進(jìn)程的代碼序列一般是:

submit_bio()

io_schedule(),放棄CPU。

blk_end_request()一般把io_schedule()后放棄CPU的進(jìn)程喚醒。io_schedule()的這段等待時間,會計(jì)算到進(jìn)程的iowait時間上,詳見:《朱輝(茶水):Linux Kernel iowait 時間的代碼原理》。

用Ftrace抓所有流程

本文所涉及到的所有流程,都可以用ftrace跟蹤到。這樣可以了解更多更深刻的細(xì)節(jié)。

char buf[4096];

sleep(30); //run ./funtion.sh to trace vfs_read of this process

fd = open("file", O_RDONLY);

read(fd, buf, 4096);

在上述代碼的中間,我特意留下了30秒的延時,在這個延時的空擋,你可以啟動如下的腳本,來對整個過程進(jìn)行function graph的trace,抓取進(jìn)程對vfs_read()開始后的調(diào)用棧:

#!/bin/bash

debugfs=/sys/kernel/debug

echo nop > $debugfs/tracing/current_tracer

echo 0 > $debugfs/tracing/tracing_on

echo `pidof read` > $debugfs/tracing/set_ftrace_pid

echo function_graph > $debugfs/tracing/current_tracer

echo vfs_read > $debugfs/tracing/set_graph_function

echo 1 > $debugfs/tracing/tracing_on

筆者也是通過ftrace的結(jié)果,用vim打開,逐句分析的。關(guān)于ftrace使用的詳細(xì)方法,可以閱讀《宋寶華:關(guān)于Ftrace的一個完整案例》。

535d1cbc-7b6f-11ee-939d-92fbcf53809c.jpg

最后的話

本文描述的是主干,許多的細(xì)節(jié)和代碼分支沒有涉及,因?yàn)樵诒疚拿枋鎏嗟姆种В瑫屪x者抓不住主干。很多分支都沒有介紹,比如unplug的泄洪,除了可以人為的blk_finish_plug()泄洪外,也會發(fā)生plug隊(duì)列較滿的時候,以及進(jìn)程睡眠schedule()的時候的自動泄洪。另外,關(guān)于寫,后面的三進(jìn)三出的過程,基本與讀類似,但是寫有個page cache堆積和writeback的啟動機(jī)制,是read所沒有的。

審核編輯:湯梓紅

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報(bào)投訴
  • 硬盤
    +關(guān)注

    關(guān)注

    3

    文章

    1336

    瀏覽量

    58295
  • Linux
    +關(guān)注

    關(guān)注

    87

    文章

    11494

    瀏覽量

    213204
  • 內(nèi)存
    +關(guān)注

    關(guān)注

    8

    文章

    3115

    瀏覽量

    75111
  • Linux系統(tǒng)
    +關(guān)注

    關(guān)注

    4

    文章

    604

    瀏覽量

    28445
  • 代碼
    +關(guān)注

    關(guān)注

    30

    文章

    4893

    瀏覽量

    70433

原文標(biāo)題:宋寶華:Linux文件讀寫(BIO)波瀾壯闊的一生

文章出處:【微信號:LinuxDev,微信公眾號:Linux閱碼場】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關(guān)推薦
    熱點(diǎn)推薦

    Linux文件系統(tǒng)與IO流程和模型

    今晚9點(diǎn): 《Linux文件系統(tǒng)與IO流程和模型》微課(415-418)
    發(fā)表于 06-13 16:51

    Linux文件系統(tǒng)啟動流程

    Linux 命令的結(jié)合使用Linux 文件系統(tǒng)啟動流程sysvinit服務(wù)的管理與裁剪systemd服務(wù)的管理與裁剪了解 qt4、qt5 的移植了解 yocto構(gòu)建
    發(fā)表于 12-17 06:00

    Linux文件系統(tǒng)課程

    本章學(xué)習(xí)目標(biāo)理解什么是文件系統(tǒng)了解文件系統(tǒng)工作原理理解Fedora Core Linux文件系統(tǒng)的結(jié)構(gòu)掌握Fedora Core Linux
    發(fā)表于 04-10 17:07 ?0次下載

    文件I/O編程之文件讀寫及上鎖實(shí)驗(yàn)

    6.6 實(shí)驗(yàn)內(nèi)容 6.6.1 文件讀寫及上鎖 1.實(shí)驗(yàn)?zāi)康?通過編寫文件讀寫及上鎖的程序,進(jìn)一步熟悉Linux
    發(fā)表于 10-18 17:34 ?0次下載
    <b class='flag-5'>文件</b>I/O編程之<b class='flag-5'>文件</b><b class='flag-5'>讀寫</b>及上鎖實(shí)驗(yàn)

    Linux設(shè)備驅(qū)動開發(fā)詳解》第5章、Linux文件系統(tǒng)與設(shè)備文件系統(tǒng)

    Linux設(shè)備驅(qū)動開發(fā)詳解》第5章、Linux文件系統(tǒng)與設(shè)備文件系統(tǒng)
    發(fā)表于 10-27 14:13 ?0次下載
    《<b class='flag-5'>Linux</b>設(shè)備驅(qū)動開發(fā)詳解》第5章、<b class='flag-5'>Linux</b><b class='flag-5'>文件系統(tǒng)</b>與設(shè)備<b class='flag-5'>文件系統(tǒng)</b>

    linux文件系統(tǒng)基礎(chǔ)

    一 、linux文件結(jié)構(gòu) 文件結(jié)構(gòu)是文件存放在磁盤等存貯設(shè)備上的組織方法。主要體現(xiàn)在對文件和目錄的組織上。 目錄提供了管理
    發(fā)表于 11-07 15:28 ?0次下載

    可以了解的Linux 文件系統(tǒng)結(jié)構(gòu)

    Linux中的文件是什么?它的文件系統(tǒng)又是什么?那些配置文件又在哪里?我下載好的程序保存在哪里了?在 Linux
    發(fā)表于 04-27 14:06 ?827次閱讀
    可以了解的<b class='flag-5'>Linux</b> <b class='flag-5'>文件系統(tǒng)</b>結(jié)構(gòu)

    需要了解的Linux內(nèi)核讀寫文件

    在用戶態(tài),讀寫文件可以通過read和write這兩個系統(tǒng)調(diào)用來完成(C庫函數(shù)實(shí)際上是對系統(tǒng)調(diào)用的封裝)。 但是,在內(nèi)核態(tài)沒有這樣的系統(tǒng)調(diào)用,
    發(fā)表于 04-28 16:43 ?1169次閱讀

    Linux系統(tǒng)日志文件中的JFS文件系統(tǒng)

    嵌入式linux中文站向大家介紹一下JFS文件系統(tǒng)Linux系統(tǒng)日志文件中的JFS系統(tǒng), JF
    發(fā)表于 05-05 14:10 ?5307次閱讀
    <b class='flag-5'>Linux</b><b class='flag-5'>系統(tǒng)</b>日志<b class='flag-5'>文件</b>中的JFS<b class='flag-5'>文件系統(tǒng)</b>

    Linux文件系統(tǒng)解析

    Linux 中,最直觀、最可見的部分就是 文件系統(tǒng)(file system)。下面我們就來一起探討一下關(guān)于 Linux 中國的文件系統(tǒng)系統(tǒng)
    的頭像 發(fā)表于 09-16 11:29 ?2729次閱讀
    <b class='flag-5'>Linux</b><b class='flag-5'>文件系統(tǒng)</b>解析

    LINUX操作系統(tǒng)的安裝與Linux常用文件命令

    LINUX操作系統(tǒng)的安裝與Linux常用文件命令說明。
    發(fā)表于 06-02 17:45 ?3次下載

    嵌入式linux系統(tǒng)中常用的文件系統(tǒng)

    原文:https://blog.csdn.net/li_wen01/article/details/80090624嵌入式linux系統(tǒng)中常用的文件系統(tǒng):閃存主要有NOR和NAND兩種技術(shù);因?yàn)?/div>
    發(fā)表于 11-01 16:56 ?12次下載
    嵌入式<b class='flag-5'>linux</b><b class='flag-5'>系統(tǒng)</b>中常用的<b class='flag-5'>文件系統(tǒng)</b>

    Linux I/O 接口的類型及處理流程

    Linux I/O 接口 Linux I/O 接口可以分為以下幾種類型: 文件 I/O 接口:用于對文件進(jìn)行讀寫操作的接口,包括 open(
    的頭像 發(fā)表于 11-08 16:43 ?1275次閱讀
    <b class='flag-5'>Linux</b> I/O 接口的類型及處理<b class='flag-5'>流程</b>

    Linux文件系統(tǒng)特點(diǎn)

    Linux文件系統(tǒng)特點(diǎn) 文件系統(tǒng)要有嚴(yán)格的組織形式,使得文件能夠以塊為單位進(jìn)行存儲。 文件系統(tǒng)中也要有索引區(qū),用來方便查找一個
    的頭像 發(fā)表于 11-09 14:48 ?1603次閱讀
    <b class='flag-5'>Linux</b>的<b class='flag-5'>文件系統(tǒng)</b>特點(diǎn)

    Linux文件系統(tǒng)的掛載過程

    Linux文件系統(tǒng)(rootfs)是Linux系統(tǒng)中所有其他文件系統(tǒng)和目錄的起點(diǎn),它是內(nèi)核啟動時掛載的第一個
    的頭像 發(fā)表于 10-05 16:50 ?905次閱讀

    電子發(fā)燒友

    中國電子工程師最喜歡的網(wǎng)站

    • 2931785位工程師會員交流學(xué)習(xí)
    • 獲取您個性化的科技前沿技術(shù)信息
    • 參加活動獲取豐厚的禮品