塊存儲硬碟

A. 不跨塊存儲什麼意思

不跨塊存儲意思是：傳統磁碟陣列：基本磁碟陣列都是商用產品，而每個廠家基本上都做好了圖形化管理界面，因此對於日常的運維操作，基本上只要在圖形化界面上面進行點選，就可以完成。並且一旦出現問題，還可以開CASE尋求廠家協助。畢竟存儲的是數據，是企業的核心生產力，一旦數據丟失，或者不可訪問，非同小可。
軟體定義存儲：有很多ceph、swift等的開源分布式存儲軟體，可以自己搭建。最穩定的是軟硬一體的設備（但是本質上還是存儲品牌綁定，跨品牌不兼容的問題），坑最多的是純軟體的版本（例如VSAN，不但購買的硬體必須是在VSAN的兼容性列表裡面的，而且對於驅動、版本等需要匹配到微碼級別，否則可能會出現兼容性問題，開CASE都解決不了），而可擴展性最好但是易用性最差的當然是開源的版本。（基本上都要命令行操作，而且需要具備能力非常強的運維團隊，否則一旦出現故障，是沒有任何外部里能可以支援的）

B. 對象存儲、文件存儲和塊存儲有什麼區別

區別如下：

1、速度不同

塊存儲：低延遲（10ms），熱點突出；

文件存儲：不同技術各有不同；

對象存儲：100ms-1s，冷數據；

2、可分步性不同

塊存儲：異地不現實；

文件存儲：可分布式，但有瓶頸；

對象存儲：分步並發能力高；

3、文件大小不同

塊存儲：大小都可以，熱點突出；

文件存儲：適合大文件；

對象存儲：適合各種大小；

4、介面不同

塊存儲：Driver，kernel mole ；

文件存儲：POSIX；

對象存儲：Restful API ；

5、典型技術不同

塊存儲：SAN；

文件存儲：HDFS，GFS；

對象存儲：Swift，Amazon S3；

6、適合場景不同

塊存儲：銀行；

文件存儲：數據中心；

對象存儲：網路媒體文件存儲；

(2)塊存儲硬碟擴展閱讀：

文件存儲的優缺點：

優點

（1）、造價低：隨便一台機器就可以，另外普通的乙太網就可以，根本不需要專用的SAN網路，所以造價低。

（2）、方便文件共享。

缺點

（1）、讀寫速率低，傳輸速率慢：乙太網，上傳下載速度較慢，另外所有讀寫都要1台伺服器裡面的硬碟來承受，相比起磁碟陣列動不動就十幾上百塊硬碟同時讀寫，速率慢了許多。

C. 2020-12-02 硬碟如何存儲文件

系統中所有內容是以文件（文件夾是特殊的文件）存在的，而文件分為屬性（元信息）和內容兩部分，磁碟一部分被操作系統虛擬為塊用來存儲數據，同時也分出一部分虛擬為Inode用來存儲文件屬性，這樣磁碟就分為塊區和inode區。

扇區：磁碟存儲數據的最小物理單元，每個扇區很小512位元組左右。
讀取數據：OS要想讀取磁碟數據，首先讓磁頭徑向尋道（最慢），然後旋轉磁碟（較快），使磁頭到達目標扇區，開始讀取數據。

磁碟塊：OS日常工作中，一個扇區的512位元組數據很小，不足以支撐絕大部分工作場景，所以需要頻繁讀取單個扇區，而磁碟讀取數據速度相對CPU處理太慢了，所以讀磁碟時一次就多拿出幾個扇區（臨近的，無需耗費額外時間）的數據，於是在OS層面邏輯虛擬出磁碟塊（簇）的概念，一個磁碟塊一般對應8個連續扇區（也可4、16個等，由OS決定），這樣OS層面就使用磁碟塊作為最小數據存儲單元。
這樣的好處當然是更高效，缺點則是會？

inode：用於存儲文件的元信息（除名稱外的所有屬性，名稱存在文件夾的內容中）
Inode number is also known as index number. An inode is a unique number assigned to files and directories while it is created. The inode number will be unique to entire filesystem.

Disk inodes contain the following information:

Owner identifier
Type of file (regular, directory, character or block device)
Access permissions
Times and dates
· file creation time

· last file access time

· last inode modification time

Number of links to the file
Array of pointers to data blocks on disk
File size (in bytes, sometimes also in blocks)

文件：
上文提及文件屬性存在磁碟inode區的inode（每個都有編號）內，而內容存儲在塊區的塊中。

文件夾：
作為特殊文件，其組織文件及目錄，屬性也是存在inode內，而存儲的內容是一個包含多個{ 文件名:對應inode Id} 的列表，內容亦存在塊區的塊中。

這樣在OS中查看一個文件（比如/etc/fstab）的內容，大概是：
首先OS獲取到根目錄的inodeId >在inode區中讀取到其屬性（某項是內容所在塊）>在塊區讀取到根目錄內容>在內容中找到名為/etc對應發inodeId>/etc在inode區的屬性>讀取到塊中/etc的內容（包含/etc/fstab對應inodeId）>/etc/fstab Inode Id > 在inode區讀取到/etc/fstab屬性 >/etc/fstab塊。

可能有誤，望指點。

Within each file system, the mapping from names to blocks is handled through a structure called an i-node. There's a pool of these things near the "bottom" (lowest-numbered blocks) of each file system (the very lowest ones are used for housekeeping and labeling purposes we won't describe here). Each i-node describes one file. File data blocks (including directories) live above the i-nodes (in higher-numbered blocks).

Every i-node contains a list of the disk block numbers in the file it describes. (Actually this is a half-truth, only correct for small files, but the rest of the details aren't important here.) Note that the i-node does not contain the name of the file.

Names of files live in directory structures. A directory structure just maps names to i-node numbers. This is why, in Unix, a file can have multiple true names (or hard links); they're just multiple directory entries that happen to point to the same i-node.

refer: https://unix.stackexchange.com/questions/432655/why-does-using-indirect-pointers-in-inodes-not-incur-the-same-amount-of-space

less:by direct list blocks in node?.
large :by two-level indirect block
larger : multi-level indirect block.

The original hierarchy of the inodes levels works roughly like this:

You can store one or a few block numbers directly in the inode. This means you use a few bytes more for the inode, but for small files, you don't have to allocate a complete block, which is mostly empty.

The next level is one indirection: You allocate a block to store the block pointers. Only the address of this indirect block is stored in the inode. This doesn't use somehow "less space", and most filesystems, even early ones, worked like that (have a pointer near the inode/filename which points to a block, which stores the block numbers of the file).

But what do you do when the space in this block runs out? You have to allocate another block, but where do you store the reference to this block? You could just add those references to the inode, but to store largers files, the inode would get large. And you want small inodes, so as many as possible inodes can fit into a single block (less disk access to read more inodes).

So you use a two-level indirect block: You just add one pointer to the inode, then you have a whole block to store pointers to indirect blocks, and the indirect blocks store the block address of the file itself.

And so on, you can add higher-level indirect blocks, or stop at some stage, until you reach the maximal size of a file possible with the structure you want.

So the point is not "use up less space in total", but "use a scheme that uses blocks efficiently for the expected distribution a files wrt. to size, i.e. many small files, some larger files, and very few huge files".

Page tables on the other hand work very differently.

Edit

To answer the questions in the comment:

Data blocks are of fixed sizes (originally 512 bytes, IIRC), which is a multiple of the block size of the underlying harddisks. So data block size can't "decrease".

As I tried to describe above, the whole point of having the inodes not use up too much space is to make inode access faster (or, alternatively, make caching inodes use up less memory - back then when the unix file system with inodes was invented, computers had a lot less memory than today). It's not about somehow saving space in total. As you say yourself, everything has to be stored somewhere, and if it doesn't use up space at location X, it will use up space at location Y.

Just adding a variable number of block pointers to the inode is not practical, because the inode must take up a fixed amount of space - you want to use the inode number to calculate the block address and the offset inside the block where the inode information is stored. You can't do that if every inode has a different size. So there must be some form of indirection.

Page tables work differently because hardware implements them differently - that's just how it is. The hierarchy has a fixed depth, always the same (though sometimes configurable. And while reading a block from disk is slow, that doesn't matter for page tables. So the design issues are completely different.

http://www.cems.uwe.ac.uk/~irjohnso/coursenotes/lrc/internals/filestore/fs3.htm

Assuming, for the purposes of illustration, that each disk data block is 1024 bytes in size, then these ten data block pointers will allow files to be created that are up to 10 Kb in size. As you can see, for the large majority of files it should be possible to access the data with nothing more than a direct lookup required to find the data block that contains any particular data byte.

With this scheme, once a file has grown to 10 Kb, there are only three block pointers in the inode left to use, whatever the eventual size of the file. Obviously, some new arrangement must be found so that the three remaining block pointers will suffice for any realistic file size, while at the same time not degrading the data access time too much.

This goal is achieved by using the idea of indirect block pointers. Specifically, when an 11th data block needs to be allocated to the file, the 11th inode block pointer is used, but instead of pointing to the block which will contain the data, the 11th pointer is a single indirect pointer which points to a data block filled with a list of direct block pointers. In our example, if we assume that a data block number is a 32-bit value, then a list of 256 of them will fit into the single indirect block. This list will point directly to the data blocks for the next 256 Kb of our file. This means that with 11 block pointers in the inode, files of up to 266 Kb (10 + 256) can be created. True, it takes a little longer to access the data beyond the first 10 Kb in the file, but it takes only one extra disk block read to find the position on the disk of the required data.

For files bigger than 266 Kb the double indirect (12th) inode block pointer is used. This is the same idea as the previous inode pointer except that the double indirect pointer points to a list of pointers in a data block, each of which is itself a single indirect block pointer which points to a list of 256 direct block pointers. This means that the 12th inode block pointer gives access to the next 65536 Kb (256x256) of data in our file.

By now, you should be able to spot the pattern and see that when the file grows bigger than 64 Mb (actually 65802 Kb), the inode's 13th data block pointer will be used, but this time as a triple indirect pointer, which will give access to a staggering 16 Gb (256x256x256 Kb) of extra file space. A single file bigger than 16Gb sounds huge. However, even though the calculation we have just done suggests that this file size is possible with the inode layout as given, in fact there are other factors which limit the maximum size of a file to a smaller value than this. For example, the size of a file, in bytes, is stored separately in its inode in a field of type unsigned long. This is a 32-bit number which limits the size of a file to 4 Gb, so that 13 data block pointers in an inode really are enough.

10.4. How a file gets looked up
Now we can look at the file system from the top down. When you open a file (such as, say, /home/esr/WWW/ldp/fundamentals.xml) here is what happens:

Your kernel starts at the root of your Unix file system (in the root partition). It looks for a directory there called 『home』. Usually 『home』 is a mount point to a large user partition elsewhere, so it will go there. In the top-level directory structure of that user partition, it will look for a entry called 『esr』 and extract an i-node number. It will go to that i-node, notice that its associated file data blocks are a directory structure, and look up 『WWW』. Extracting that i-node, it will go to the corresponding subdirectory and look up 『ldp』. That will take it to yet another directory i-node. Opening that one, it will find an i-node number for 『fundamentals.xml』. That i-node is not a directory, but instead holds the list of disk blocks associated with the file.

The surface area of your disk, where it stores data, is divided up something like a dartboard — into circular tracks which are then pie-sliced into sectors. Because tracks near the outer edge have more area than those close to the spindle at the center of the disk, the outer tracks have more sector slices in them than the inner ones. Each sector (or disk block ) has the same size, which under modern Unixes is generally 1 binary K (1024 8-bit bytes). Each disk block has a unique address or disk block number .

Unix divides the disk into disk partitions . Each partition is a continuous span of blocks that's used separately from any other partition, either as a file system or as swap space. The original reasons for partitions had to do with crash recovery in a world of much slower and more error-prone disks; the boundaries between them rece the fraction of your disk likely to become inaccessible or corrupted by a random bad spot on the disk. Nowadays, it's more important that partitions can be declared read-only (preventing an intruder from modifying critical system files) or shared over a network through various means we won't discuss here. The lowest-numbered partition on a disk is often treated specially, as a boot partition where you can put a kernel to be booted.

Each partition is either swap space (used to implement virtual memory ) or a file system used to hold files. Swap-space partitions are just treated as a linear sequence of blocks. File systems, on the other hand, need a way to map file names to sequences of disk blocks. Because files grow, shrink, and change over time, a file's data blocks will not be a linear sequence but may be scattered all over its partition (from wherever the operating system can find a free block when it needs one). This scattering effect is called fragmentation .

Within each file system, the mapping from names to blocks is handled through a structure called an i-node . There's a pool of these things near the "bottom" (lowest-numbered blocks) of each file system (the very lowest ones are used for housekeeping and labeling purposes we won't describe here). Each i-node describes one file. File data blocks (including directories) live above the i-nodes (in higher-numbered blocks).

Every i-node contains a list of the disk block numbers in the file it describes. (Actually this is a half-truth, only correct for small files, but the rest of the details aren't important here.) Note that the i-node does not contain the name of the file.

Names of files live in directory structures . A directory structure just maps names to i-node numbers. This is why, in Unix, a file can have multiple true names (or hard links ); they're just multiple directory entries that happen to point to the same i-node.

In the simplest case, your entire Unix file system lives in just one disk partition. While you'll see this arrangement on some small personal Unix systems, it's unusual. More typical is for it to be spread across several disk partitions, possibly on different physical disks. So, for example, your system may have one small partition where the kernel lives, a slightly larger one where OS utilities live, and a much bigger one where user home directories live.

The only partition you'll have access to immediately after system boot is your root partition , which is (almost always) the one you booted from. It holds the root directory of the file system, the top node from which everything else hangs.

The other partitions in the system have to be attached to this root in order for your entire, multiple-partition file system to be accessible. About midway through the boot process, your Unix will make these non-root partitions accessible. It will mount each one onto a directory on the root partition.

For example, if you have a Unix directory called <tt class="filename">/usr</tt>, it is probably a mount point to a partition that contains many programs installed with your Unix but not required ring initial boot.

D. 塊存儲、文件存儲、對象存儲這三者的本質差別是什麼

一、概念及區別

針對不同的應用場景，選擇的分布式存儲方案也會不同，因此有了對象存儲、塊存儲、文件系統存儲。這三者的主要區別在於它們的存儲介面：

1. 對象存儲:

也就是通常意義的鍵值存儲，其介面就是簡單的GET,PUT,DEL和其他擴展，

2. 塊存儲:

這種介面通常以QEMU Driver或者Kernel Mole的方式存在，這種介面需要實現Linux的BlockDevice的介面或者QEMU提供的BlockDriver介面，如Sheepdog，AWS的EBS，青雲的雲硬碟和阿里雲的盤古系統，還有Ceph的RBD(RBD是Ceph面向塊存儲的介面)

3. 文件存儲:

通常意義是支持POSIX介面，它跟傳統的文件系統如Ext4是一個類型的，但區別在於分布式存儲提供了並行化的能力，如Ceph的CephFS(CephFS是Ceph面向文件存儲的介面)，但是有時候又會把GFS，HDFS這種非POSIX介面的類文件存儲介面歸入此類。

二、IO特點

按照這三種介面和其應用場景，很容易了解這三種類型的IO特點，括弧里代表了它在非分布式情況下的對應:1. 對象存儲(鍵值資料庫):

介面簡單，一個對象我們可以看成一個文件，只能全寫全讀，通常以大文件為主，要求足夠的IO帶寬。

2. 塊存儲(硬碟):

它的IO特點與傳統的硬碟是一致的，一個硬碟應該是能面向通用需求的，即能應付大文件讀寫，也能處理好小文件讀寫。但是硬碟的特點是容量大，熱點明顯。因此塊存儲主要可以應付熱點問題。另外，塊存儲要求的延遲是最低的。

3. 文件存儲(文件系統):

支持文件存儲的介面的系統設計跟傳統本地文件系統如Ext4這種的特點和難點是一致的，它比塊存儲具有更豐富的介面，需要考慮目錄、文件屬性等支持，實現一個支持並行化的文件存儲應該是最困難的。但像HDFS、GFS這種自己定義標準的系統，可以通過根據實現來定義介面，會容易一點。

因此，這三種介面分別以非分布式情況下的鍵值資料庫、硬碟和文件系統的IO特點來對應即可。至於冷熱、快慢、大小文件而言更接近於業務。但是因為存儲系統是通用化實現，通常來說，需要盡量滿足各種需求，而介面定義已經一定意義上就砍去了一些需求，如對象存儲會以冷存儲更多，大文件為主。

E. 固態硬碟盒是什麼 固態硬碟盒介紹

1、固態硬碟（Solid State Disk、Solid State Drive，簡稱SSD，准確的技術稱呼應為固態驅動器）是一種基於永久性存儲器，如快閃記憶體，或非永久性存儲器，同步動態隨機存取存儲器（SDRAM）的計算機外部存儲設備。固態硬碟用來在攜帶型計算機中代替常規硬碟。雖然在固態硬碟中已經沒有可以旋轉的盤狀結構，但是依照人們的命名習慣，這類存儲器仍然被稱為「硬碟」。

2、由於固態硬碟技術與傳統硬碟技術不同，所以產生了不少新興的存儲器廠商。廠商只需購買NAND Flash存儲器，再配合適當的控制晶元，就可以製造固態硬碟了。新一代的固態硬碟普遍採用SATA-2介面。

3、固態硬碟大部分被製作成與常規硬碟相同的外形，例如常見的1.8英寸、2.5英寸或3.5英寸規格，並採用了相互兼容的介面；但有些固態硬碟也使用 PCI Express 或是 Express Card 作為介面來突破現有硬碟傳輸介面的速度，或是在有限空間（如筆記本電腦）中置放固態硬碟。

4、固態硬碟採用的存儲塊存儲數據，類似U盤的結構原理。普通硬碟採用的是磁碟介質方式。存在機械結構帶動磁碟轉動來達到工作的。

F. 雲存儲和傳統硬碟存儲有哪些優缺點

給個水一點的回答,考慮到刻錄機的老化和兼容性之類的問題,普通光碟的存儲時間應該不如硬碟,機械硬碟不如u盤和ssd,光碟當然是避光低溫保存最好。雲存儲的優點就是存儲方便分享也方便,共有部分的數據冗餘度低,缺點就是對網路依賴大,對政策依賴大,安全性值得擔憂。
採納哦

G. 一個文件如何被分塊存儲在磁碟上

數據存儲在硬碟的時候都以簇位單位簇的配置Windows9x/Me系統中常用的文件簇通常為FAT16或者FAT32格式比如一個256M的硬碟空間可以有數種配置簇的方式：簇大小＝4KB：256MB/4KB＝655356個簇簇大小＝8KB：256MB/8KB＝32768個簇簇大小＝16KB：256MB/16KB＝16384個簇簇大小＝32KB：256MB/32KB＝8192個簇對於WindowsNT/2000/XP特有的NTFS文件系統來說，雖然也是採用簇方式來存儲數據，但它卻和FAT16/FAT32有著明顯的不同。當分區空間大於2GB的時候，無論硬碟有多大，簇的大小一律維持在4KB。由於簇容量小，所以無論存儲何種類型的文件都不會浪費太多的硬碟空間，這也使得整個硬碟的空間利用率得到了極大的提高。

H. 什麼是系統在硬碟上開辟的一塊儲存空間，用於在cpu與內存之間快速交換數據

虛擬內存。
當計算機隨機存儲器RAM不足時，操作系統用虛擬存儲器進行補償，緩解內存緊張，虛擬內存由硬體和操作系統自動實現存儲信息調度和管理的。
虛擬內存越高系統越流暢，它使得應用程序認為它擁有連續的可用的內存一個連續完整的地址空間，而實際上它通常是被分隔成多個物理內存碎片，還有部分暫時存儲在外部磁碟存儲器上，在需要時進行數據交換。