From 957348e3e4ed6b94ee4cea3d328dfa87be9e8a73 Mon Sep 17 00:00:00 2001 From: chenxinlong <237448382@qq.com> Date: Fri, 26 May 2017 23:19:53 +0800 Subject: [PATCH 01/17] =?UTF-8?q?=E5=8F=96=E6=B6=88=E7=BF=BB=E8=AF=91?= =?UTF-8?q?=EF=BC=8C=E6=AD=A4=E7=AF=87=E5=85=B6=E4=BB=96=E5=B9=B3=E5=8F=B0?= =?UTF-8?q?=E5=B7=B2=E7=BB=8F=E6=9C=89=E8=AF=91=E6=96=87=E4=BA=86?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- sources/tech/20170303 A Programmes Introduction to Unicode.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/sources/tech/20170303 A Programmes Introduction to Unicode.md b/sources/tech/20170303 A Programmes Introduction to Unicode.md index 4724955c87..0e4bd2b1b7 100644 --- a/sources/tech/20170303 A Programmes Introduction to Unicode.md +++ b/sources/tech/20170303 A Programmes Introduction to Unicode.md @@ -1,4 +1,3 @@ -translating by chenxinlong [A Programmer’s Introduction to Unicode][18] ============================================================ @@ -224,7 +223,7 @@ You can contact me at nathaniel dot reed at gmail dot com, or follow me on Twitt via: http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311 作者：[ Nathan][a] -译者：[译者ID](https://github.com/chenxinlong) +译者：[译者ID](https://github.com/译者ID) 校对：[校对者ID](https://github.com/校对者ID) 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 From f75eeb143e5dd8dcde9942456a40b308b4e99c17 Mon Sep 17 00:00:00 2001 From: chenxinlong <237448382@qq.com> Date: Tue, 30 May 2017 18:49:16 +0800 Subject: [PATCH 02/17] translating by chenxinlong --- .../20170525 An introduction to Linux s EXT4 filesystem.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md b/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md index d35168fcba..ecb2084da7 100644 --- a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md +++ b/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md @@ -1,3 +1,4 @@ +Translating by chenxinlong An introduction to Linux's EXT4 filesystem ============================================================ @@ -260,7 +261,7 @@ David Both - David Both is a Linux and Open Source advocate who resides in Ralei via: https://opensource.com/article/17/5/introduction-ext4-filesystem 作者：[David Both ][a] -译者：[译者ID](https://github.com/译者ID) +译者：[译者ID](https://github.com/chenxinlong) 校对：[校对者ID](https://github.com/校对者ID) 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 From 97eaba02480c15dd8148ed56b6cbe5623848b3dc Mon Sep 17 00:00:00 2001 From: chenxinlong <237448382@qq.com> Date: Tue, 30 May 2017 18:51:45 +0800 Subject: [PATCH 03/17] deleted article removed by origin --- ...03 A Programmes Introduction to Unicode.md | 290 ------------------ 1 file changed, 290 deletions(-) delete mode 100644 sources/tech/20170303 A Programmes Introduction to Unicode.md diff --git a/sources/tech/20170303 A Programmes Introduction to Unicode.md b/sources/tech/20170303 A Programmes Introduction to Unicode.md deleted file mode 100644 index 0e4bd2b1b7..0000000000 --- a/sources/tech/20170303 A Programmes Introduction to Unicode.md +++ /dev/null @@ -1,290 +0,0 @@ -[A Programmer’s Introduction to Unicode][18] -============================================================ - - -Ｕｎｉｃｏｄｅ! 🅤🅝🅘🅒🅞🅓🅔‽ 🇺‌🇳‌🇮‌🇨‌🇴‌🇩‌🇪! 😄 The very name strikes fear and awe into the hearts of programmers worldwide. We all know we ought to “support Unicode” in our software (whatever that means—like using `wchar_t` for all the strings, right?). But Unicode can be abstruse, and diving into the thousand-page [Unicode Standard][27] plus its dozens of supplementary [annexes, reports][28], and [notes][29]can be more than a little intimidating. I don’t blame programmers for still finding the whole thing mysterious, even 30 years after Unicode’s inception. - -A few months ago, I got interested in Unicode and decided to spend some time learning more about it in detail. In this article, I’ll give an introduction to it from a programmer’s point of view. - -I’m going to focus on the character set and what’s involved in working with strings and files of Unicode text. However, in this article I’m not going to talk about fonts, text layout/shaping/rendering, or localization in detail—those are separate issues, beyond my scope (and knowledge) here. - -* [Diversity and Inherent Complexity][10] -* [The Unicode Codespace][11] - * [Codespace Allocation][2] - * [Scripts][3] - * [Usage Frequency][4] -* [Encodings][12] - * [UTF-8][5] - * [UTF-16][6] -* [Combining Marks][13] - * [Canonical Equivalence][7] - * [Normalization Forms][8] - * [Grapheme Clusters][9] -* [And More…][14] - -### [][30]Diversity and Inherent Complexity - -As soon as you start to study Unicode, it becomes clear that it represents a large jump in complexity over character sets like ASCII that you may be more familiar with. It’s not just that Unicode contains a much larger number of characters, although that’s part of it. Unicode also has a great deal of internal structure, features, and special cases, making it much more than what one might expect a mere “character set” to be. We’ll see some of that later in this article. - -When confronting all this complexity, especially as an engineer, it’s hard not to find oneself asking, “Why do we need all this? Is this really necessary? Couldn’t it be simplified?” - -However, Unicode aims to faithfully represent the  _entire world’s_  writing systems. The Unicode Consortium’s stated goal is “enabling people around the world to use computers in any language”. And as you might imagine, the diversity of written languages is immense! To date, Unicode supports 135 different scripts, covering some 1100 languages, and there’s still a long tail of [over 100 unsupported scripts][31], both modern and historical, which people are still working to add. - -Given this enormous diversity, it’s inevitable that representing it is a complicated project. Unicode embraces that diversity, and accepts the complexity inherent in its mission to include all human writing systems. It doesn’t make a lot of trade-offs in the name of simplification, and it makes exceptions to its own rules where necessary to further its mission. - -Moreover, Unicode is committed not just to supporting texts in any  _single_  language, but also to letting multiple languages coexist within one text—which introduces even more complexity. - -Most programming languages have libaries available to handle the gory low-level details of text manipulation, but as a programmer, you’ll still need to know about certain Unicode features in order to know when and how to apply them. It may take some time to wrap your head around it all, but don’t be discouraged—think about the billions of people for whom your software will be more accessible through supporting text in their language. Embrace the complexity! - -### [][32]The Unicode Codespace - -Let’s start with some general orientation. The basic elements of Unicode—its “characters”, although that term isn’t quite right—are called  _code points_ . Code points are identified by number, customarily written in hexadecimal with the prefix “U+”, such as [U+0041 “A” latin capital letter a][33] or [U+03B8 “θ” greek small letter theta][34]. Each code point also has a short name, and quite a few other properties, specified in the [Unicode Character Database][35]. - -The set of all possible code points is called the  _codespace_ . The Unicode codespace consists of 1,114,112 code points. However, only 128,237 of them—about 12% of the codespace—are actually assigned, to date. There’s plenty of room for growth! Unicode also reserves an additional 137,468 code points as “private use” areas, which have no standardized meaning and are available for individual applications to define for their own purposes. - -### [][36]Codespace Allocation - -To get a feel for how the codespace is laid out, it’s helpful to visualize it. Below is a map of the entire codespace, with one pixel per code point. It’s arranged in tiles for visual coherence; each small square is 16×16 = 256 code points, and each large square is a “plane” of 65,536 code points. There are 17 planes altogether. - -[ - ![Map of the Unicode codespace (click to zoom)](http://reedbeta.com/blog/programmers-intro-to-unicode/codespace-map.png "Map of the Unicode codespace (click to zoom)") -][37] - -White represents unassigned space. Blue is assigned code points, green is private-use areas, and the small red area is surrogates (more about those later). As you can see, the assigned code points are distributed somewhat sparsely, but concentrated in the first three planes. - -Plane 0 is also known as the “Basic Multilingual Plane”, or BMP. The BMP contains essentially all the characters needed for modern text in any script, including Latin, Cyrillic, Greek, Han (Chinese), Japanese, Korean, Arabic, Hebrew, Devanagari (Indian), and many more. - -(In the past, the codespace was just the BMP and no more—Unicode was originally conceived as a straightforward 16-bit encoding, with only 65,536 code points. It was expanded to its current size in 1996\. However, the vast majority of code points in modern text belong to the BMP.) - -Plane 1 contains historical scripts, such as Sumerian cuneiform and Egyptian hieroglyphs, as well as emoji and various other symbols. Plane 2 contains a large block of less-common and historical Han characters. The remaining planes are empty, except for a small number of rarely-used formatting characters in Plane 14; planes 15–16 are reserved entirely for private use. - -### [][38]Scripts - -Let’s zoom in on the first three planes, since that’s where the action is: - -[ - ![Map of scripts in Unicode planes 0–2 (click to zoom)](http://reedbeta.com/blog/programmers-intro-to-unicode/script-map.png "Map of scripts in Unicode planes 0–2 (click to zoom)") -][39] - -This map color-codes the 135 different scripts in Unicode. You can see how Han () and Korean ()take up most of the range of the BMP (the left large square). By contrast, all of the European, Middle Eastern, and South Asian scripts fit into the first row of the BMP in this diagram. - -Many areas of the codespace are adapted or copied from earlier encodings. For example, the first 128 code points of Unicode are just a copy of ASCII. This has clear benefits for compatibility—it’s easy to losslessly convert texts from smaller encodings into Unicode (and the other direction too, as long as no characters outside the smaller encoding are used). - -### [][40]Usage Frequency - -One more interesting way to visualize the codespace is to look at the distribution of usage—in other words, how often each code point is actually used in real-world texts. Below is a heat map of planes 0–2 based on a large sample of text from Wikipedia and Twitter (all languages). Frequency increases from black (never seen) through red and yellow to white. - -[ - ![Heat map of code point usage frequency in Unicode planes 0–2 (click to zoom)](http://reedbeta.com/blog/programmers-intro-to-unicode/heatmap-wiki+tweets.png "Heat map of code point usage frequency in Unicode planes 0–2 (click to zoom)") -][41] - -You can see that the vast majority of this text sample lies in the BMP, with only scattered usage of code points from planes 1–2\. The biggest exception is emoji, which show up here as the several bright squares in the bottom row of plane 1. - -### [][42]Encodings - -We’ve seen that Unicode code points are abstractly identified by their index in the codespace, ranging from U+0000 to U+10FFFF. But how do code points get represented as bytes, in memory or in a file? - -The most convenient, computer-friendliest (and programmer-friendliest) thing to do would be to just store the code point index as a 32-bit integer. This works, but it consumes 4 bytes per code point, which is sort of a lot. Using 32-bit ints for Unicode will cost you a bunch of extra storage, memory, and performance in bandwidth-bound scenarios, if you work with a lot of text. - -Consequently, there are several more-compact encodings for Unicode. The 32-bit integer encoding is officially called UTF-32 (UTF = “Unicode Transformation Format”), but it’s rarely used for storage. At most, it comes up sometimes as a temporary internal representation, for examining or operating on the code points in a string. - -Much more commonly, you’ll see Unicode text encoded as either UTF-8 or UTF-16\. These are both _variable-length_  encodings, made up of 8-bit or 16-bit units, respectively. In these schemes, code points with smaller index values take up fewer bytes, which saves a lot of memory for typical texts. The trade-off is that processing UTF-8/16 texts is more programmatically involved, and likely slower. - -### [][43]UTF-8 - -In UTF-8, each code point is stored using 1 to 4 bytes, based on its index value. - -UTF-8 uses a system of binary prefixes, in which the high bits of each byte mark whether it’s a single byte, the beginning of a multi-byte sequence, or a continuation byte; the remaining bits, concatenated, give the code point index. This table shows how it works: - -| UTF-8 (binary) | Code point (binary) | Range | -| --- | --- | --- | -| 0xxxxxxx | xxxxxxx | U+0000–U+007F | -| 110xxxxx 10yyyyyy | xxxxxyyyyyy | U+0080–U+07FF | -| 1110xxxx 10yyyyyy 10zzzzzz | xxxxyyyyyyzzzzzz | U+0800–U+FFFF | -| 11110xxx 10yyyyyy 10zzzzzz 10wwwwww | xxxyyyyyyzzzzzzwwwwww | U+10000–U+10FFFF | - -A handy property of UTF-8 is that code points below 128 (ASCII characters) are encoded as single bytes, and all non-ASCII code points are encoded using sequences of bytes 128–255\. This has a couple of nice consequences. First, any strings or files out there that are already in ASCII can also be interpreted as UTF-8 without any conversion. Second, lots of widely-used string programming idioms—such as null termination, or delimiters (newlines, tabs, commas, slashes, etc.)—will just work on UTF-8 strings. ASCII bytes never occur inside the encoding of non-ASCII code points, so searching byte-wise for a null terminator or a delimiter will do the right thing. - -Thanks to this convenience, it’s relatively simple to extend legacy ASCII programs and APIs to handle UTF-8 strings. UTF-8 is very widely used in the Unix/Linux and Web worlds, and many programmers argue [UTF-8 should be the default encoding everywhere][44]. - -However, UTF-8 isn’t a drop-in replacement for ASCII strings in all respects. For instance, code that iterates over the “characters” in a string will need to decode UTF-8 and iterate over code points (or maybe grapheme clusters—more about those later), not bytes. When you measure the “length” of a string, you’ll need to think about whether you want the length in bytes, the length in code points, the width of the text when rendered, or something else. - -### [][45]UTF-16 - -The other encoding that you’re likely to encounter is UTF-16\. It uses 16-bit words, with each code point stored as either 1 or 2 words. - -Like UTF-8, we can express the UTF-16 encoding rules in the form of binary prefixes: - -| UTF-16 (binary) | Code point (binary) | Range | -| --- | --- | --- | -| xxxxxxxxxxxxxxxx | xxxxxxxxxxxxxxxx | U+0000–U+FFFF | -| 110110xxxxxxxxxx 110111yyyyyyyyyy | xxxxxxxxxxyyyyyyyyyy + 0x10000 | U+10000–U+10FFFF | - -A more common way that people talk about UTF-16 encoding, though, is in terms of code points called “surrogates”. All the code points in the range U+D800–U+DFFF—or in other words, the code points that match the binary prefixes `110110` and `110111` in the table above—are reserved specifically for UTF-16 encoding, and don’t represent any valid characters on their own. They’re only meant to occur in the 2-word encoding pattern above, which is called a “surrogate pair”. Surrogate code points are illegal in any other context! They’re not allowed in UTF-8 or UTF-32 at all. - -Historically, UTF-16 is a descendant of the original, pre-1996 versions of Unicode, in which there were only 65,536 code points. The original intention was that there would be no different “encodings”; Unicode was supposed to be a straightforward 16-bit character set. Later, the codespace was expanded to make room for a long tail of less-common (but still important) Han characters, which the Unicode designers didn’t originally plan for. Surrogates were then introduced, as—to put it bluntly—a kludge, allowing 16-bit encodings to access the new code points. - -Today, Javascript uses UTF-16 as its standard string representation: if you ask for the length of a string, or iterate over it, etc., the result will be in UTF-16 words, with any code points outside the BMP expressed as surrogate pairs. UTF-16 is also used by the Microsoft Win32 APIs; though Win32 supports either 8-bit or 16-bit strings, the 8-bit version unaccountably still doesn’t support UTF-8—only legacy code-page encodings, like ANSI. This leaves UTF-16 as the only way to get proper Unicode support in Windows. - -By the way, UTF-16’s words can be stored either little-endian or big-endian. Unicode has no opinion on that issue, though it does encourage the convention of putting [U+FEFF zero width no-break space][46] at the top of a UTF-16 file as a [byte-order mark][47], to disambiguate the endianness. (If the file doesn’t match the system’s endianness, the BOM will be decoded as U+FFFE, which isn’t a valid code point.) - -### [][48]Combining Marks - -In the story so far, we’ve been focusing on code points. But in Unicode, a “character” can be more complicated than just an individual code point! - -Unicode includes a system for  _dynamically composing_  characters, by combining multiple code points together. This is used in various ways to gain flexibility without causing a huge combinatorial explosion in the number of code points. - -In European languages, for example, this shows up in the application of diacritics to letters. Unicode supports a wide range of diacritics, including acute and grave accents, umlauts, cedillas, and many more. All these diacritics can be applied to any letter of any alphabet—and in fact,  _multiple_  diacritics can be used on a single letter. - -If Unicode tried to assign a distinct code point to every possible combination of letter and diacritics, things would rapidly get out of hand. Instead, the dynamic composition system enables you to construct the character you want, by starting with a base code point (the letter) and appending additional code points, called “combining marks”, to specify the diacritics. When a text renderer sees a sequence like this in a string, it automatically stacks the diacritics over or under the base letter to create a composed character. - -For example, the accented character “Á” can be expressed as a string of two code points: [U+0041 “A” latin capital letter a][49] plus [U+0301 “◌́” combining acute accent][50]. This string automatically gets rendered as a single character: “Á”. - -Now, Unicode does also include many “precomposed” code points, each representing a letter with some combination of diacritics already applied, such as [U+00C1 “Á” latin capital letter a with acute][51] or [U+1EC7 “ệ” latin small letter e with circumflex and dot below][52]. I suspect these are mostly inherited from older encodings that were assimilated into Unicode, and kept around for compatibility. In practice, there are precomposed code points for most of the common letter-with-diacritic combinations in European-script languages, so they don’t use dynamic composition that much in typical text. - -Still, the system of combining marks does allow for an  _arbitrary number_  of diacritics to be stacked on any base character. The reductio-ad-absurdum of this is [Zalgo text][53], which works by ͖͟ͅr͞aṋ̫̠̖͈̗d͖̻̹óm̪͙͕̗̝ļ͇̰͓̳̫ý͓̥̟͍ ̕s̫t̫̱͕̗̰̼̘͜a̼̩͖͇̠͈̣͝c̙͍k̖̱̹͍͘i̢n̨̺̝͇͇̟͙ģ̫̮͎̻̟ͅ ̕n̼̺͈͞u̮͙m̺̭̟̗͞e̞͓̰̤͓̫r̵o̖ṷs҉̪͍̭̬̝̤ ̮͉̝̞̗̟͠d̴̟̜̱͕͚i͇̫̼̯̭̜͡ḁ͙̻̼c̲̲̹r̨̠̹̣̰̦i̱t̤̻̤͍͙̘̕i̵̜̭̤̱͎c̵s ͘o̱̲͈̙͖͇̲͢n͘ ̜͈e̬̲̠̩ac͕̺̠͉h̷̪ ̺̣͖̱ḻ̫̬̝̹ḙ̙̺͙̭͓̲t̞̞͇̲͉͍t̷͔̪͉̲̻̠͙e̦̻͈͉͇r͇̭̭̬͖,̖́ ̜͙͓̣̭s̘̘͈o̱̰̤̲ͅ ̛̬̜̙t̼̦͕̱̹͕̥h̳̲͈͝ͅa̦t̻̲ ̻̟̭̦̖t̛̰̩h̠͕̳̝̫͕e͈̤̘͖̞͘y҉̝͙ ̷͉͔̰̠o̞̰v͈͈̳̘͜er̶f̰͈͔ḻ͕̘̫̺̲o̲̭͙͠ͅw̱̳̺ ͜t̸h͇̭͕̳͍e̖̯̟̠ ͍̞̜͔̩̪͜ļ͎̪̲͚i̝̲̹̙̩̹n̨̦̩̖ḙ̼̲̼͢ͅ ̬͝s̼͚̘̞͝p͙̘̻a̙c҉͉̜̤͈̯̖i̥͡n̦̠̱͟g̸̗̻̦̭̮̟ͅ ̳̪̠͖̳̯̕a̫͜n͝d͡ ̣̦̙ͅc̪̗r̴͙̮̦̹̳e͇͚̞͔̹̫͟a̙̺̙ț͔͎̘̹ͅe̥̩͍ a͖̪̜̮͙̹n̢͉̝ ͇͉͓̦̼́a̳͖̪̤̱p̖͔͔̟͇͎͠p̱͍̺ę̲͎͈̰̲̤̫a̯͜r̨̮̫̣̘a̩̯͖n̹̦̰͎̣̞̞c̨̦̱͔͎͍͖e̬͓͘ ̤̰̩͙̤̬͙o̵̼̻̬̻͇̮̪f̴ ̡̙̭͓͖̪̤“̸͙̠̼c̳̗͜o͏̼͙͔̮r̞̫̺̞̥̬ru̺̻̯͉̭̻̯p̰̥͓̣̫̙̤͢t̳͍̳̖ͅi̶͈̝͙̼̙̹o̡͔n̙̺̹̖̩͝ͅ”̨̗͖͚̩.̯͓ - -A few other places where dynamic character composition shows up in Unicode: - -* [Vowel-pointing notation][15] in Arabic and Hebrew. In these languages, words are normally spelled with some of their vowels left out. They then have diacritic notation to indicate the vowels (used in dictionaries, language-teaching materials, children’s books, and such). These diacritics are expressed with combining marks. - - | A Hebrew example, with [niqqud][1]: | אֶת דַלְתִּי הֵזִיז הֵנִיעַ, קֶטֶב לִשְׁכַּתִּי יָשׁוֹד | - | Normal writing (no niqqud): | את דלתי הזיז הניע, קטב לשכתי ישוד | - -* [Devanagari][16], the script used to write Hindi, Sanskrit, and many other South Asian languages, expresses certain vowels as combining marks attached to consonant letters. For example, “ह” + “​ि” = “हि” (“h” + “i” = “hi”). - -* Korean characters stand for syllables, but they are composed of letters called [jamo][17] that stand for the vowels and consonants in the syllable. While there are code points for precomposed Korean syllables, it’s also possible to dynamically compose them by concatenating their jamo. For example, “ᄒ” + “ᅡ” + “ᆫ” = “한” (“h” + “a” + “n” = “han”). - -### [][54]Canonical Equivalence - -In Unicode, precomposed characters exist alongside the dynamic composition system. A consequence of this is that there are multiple ways to express “the same” string—different sequences of code points that result in the same user-perceived characters. For example, as we saw earlier, we can express the character “Á” either as the single code point U+00C1,  _or_  as the string of two code points U+0041 U+0301. - -Another source of ambiguity is the ordering of multiple diacritics in a single character. Diacritic order matters visually when two diacritics apply to the same side of the base character, e.g. both above: “ǡ” (dot, then macron) is different from “ā̇” (macron, then dot). However, when diacritics apply to different sides of the character, e.g. one above and one below, then the order doesn’t affect rendering. Moreover, a character with multiple diacritics might have one of the diacritics precomposed and others expressed as combining marks. - -For example, the Vietnamese letter “ệ” can be expressed in  _five_  different ways: - -* Fully precomposed: U+1EC7 “ệ” -* Partially precomposed: U+1EB9 “ẹ” + U+0302 “◌̂” -* Partially precomposed: U+00EA “ê” + U+0323 “◌̣” -* Fully decomposed: U+0065 “e” + U+0323 “◌̣” + U+0302 “◌̂” -* Fully decomposed: U+0065 “e” + U+0302 “◌̂” + U+0323 “◌̣” - -Unicode refers to set of strings like this as “canonically equivalent”. Canonically equivalent strings are supposed to be treated as identical for purposes of searching, sorting, rendering, text selection, and so on. This has implications for how you implement operations on text. For example, if an app has a “find in file” operation and the user searches for “ệ”, it should, by default, find occurrences of  _any_  of the five versions of “ệ” above! - -### [][55]Normalization Forms - -To address the problem of “how to handle canonically equivalent strings”, Unicode defines several _normalization forms_ : ways of converting strings into a canonical form so that they can be compared code-point-by-code-point (or byte-by-byte). - -The “NFD” normalization form fully  _decomposes_  every character down to its component base and combining marks, taking apart any precomposed code points in the string. It also sorts the combining marks in each character according to their rendered position, so e.g. diacritics that go below the character come before the ones that go above the character. (It doesn’t reorder diacritics in the same rendered position, since their order matters visually, as previously mentioned.) - -The “NFC” form, conversely, puts things back together into precomposed code points as much as possible. If an unusual combination of diacritics is called for, there may not be any precomposed code point for it, in which case NFC still precomposes what it can and leaves any remaining combining marks in place (again ordered by rendered position, as in NFD). - -There are also forms called NFKD and NFKC. The “K” here refers to  _compatibility_  decompositions, which cover characters that are “similar” in some sense but not visually identical. However, I’m not going to cover that here. - -### [][56]Grapheme Clusters - -As we’ve seen, Unicode contains various cases where a thing that a user thinks of as a single “character” might actually be made up of multiple code points under the hood. Unicode formalizes this using the notion of a  _grapheme cluster_ : a string of one or more code points that constitute a single “user-perceived character”. - -[UAX #29][57] defines the rules for what, precisely, qualifies as a grapheme cluster. It’s approximately “a base code point followed by any number of combining marks”, but the actual definition is a bit more complicated; it accounts for things like Korean jamo, and [emoji ZWJ sequences][58]. - -The main thing grapheme clusters are used for is text  _editing_ : they’re often the most sensible unit for cursor placement and text selection boundaries. Using grapheme clusters for these purposes ensures that you can’t accidentally chop off some diacritics when you copy-and-paste text, that left/right arrow keys always move the cursor by one visible character, and so on. - -Another place where grapheme clusters are useful is in enforcing a string length limit—say, on a database field. While the true, underlying limit might be something like the byte length of the string in UTF-8, you wouldn’t want to enforce that by just truncating bytes. At a minimum, you’d want to “round down” to the nearest code point boundary; but even better, round down to the nearest  _grapheme cluster boundary_ . Otherwise, you might be corrupting the last character by cutting off a diacritic, or interrupting a jamo sequence or ZWJ sequence. - -### [][59]And More… - -There’s much more that could be said about Unicode from a programmer’s perspective! I haven’t gotten into such fun topics as case mapping, collation, compatibility decompositions and confusables, Unicode-aware regexes, or bidirectional text. Nor have I said anything yet about implementation issues—how to efficiently store and look-up data about the sparsely-assigned code points, or how to optimize UTF-8 decoding, string comparison, or NFC normalization. Perhaps I’ll return to some of those things in future posts. - -Unicode is a fascinating and complex system. It has a many-to-one mapping between bytes and code points, and on top of that a many-to-one (or, under some circumstances, many-to-many) mapping between code points and “characters”. It has oddball special cases in every corner. But no one ever claimed that representing  _all written languages_  was going to be  _easy_ , and it’s clear that we’re never going back to the bad old days of a patchwork of incompatible encodings. - -Further reading: - -* [The Unicode Standard][21] -* [UTF-8 Everywhere Manifesto][22] -* [Dark corners of Unicode][23] by Eevee -* [ICU (International Components for Unicode)][24]—C/C++/Java libraries implementing many Unicode algorithms and related things -* [Python 3 Unicode Howto][25] -* [Google Noto Fonts][26]—set of fonts intended to cover all assigned code points - --------------------------------------------------------------------------------- - -作者简介： - -I’m a graphics programmer, currently freelancing in Seattle. Previously I worked at NVIDIA on the DevTech software team, and at Sucker Punch Productions developing rendering technology for the Infamous series of games for PS3 and PS4. - -I’ve been interested in graphics since about 2002 and have worked on a variety of assignments, including fog, atmospheric haze, volumetric lighting, water, visual effects, particle systems, skin and hair shading, postprocessing, specular models, linear-space rendering, and GPU performance measurement and optimization. - -You can read about what I’m up to on my blog. In addition to graphics, I’m interested in theoretical physics, and in programming language design. - -You can contact me at nathaniel dot reed at gmail dot com, or follow me on Twitter (@Reedbeta) or Google+. I can also often be found answering questions at Computer Graphics StackExchange. - -------------------- - -via: http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311 - -作者：[ Nathan][a] -译者：[译者ID](https://github.com/译者ID) -校对：[校对者ID](https://github.com/校对者ID) - -本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 - -[a]:http://reedbeta.com/about/ -[1]:https://en.wikipedia.org/wiki/Niqqud -[2]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#codespace-allocation -[3]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#scripts -[4]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#usage-frequency -[5]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#utf-8 -[6]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#utf-16 -[7]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#canonical-equivalence -[8]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#normalization-forms -[9]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#grapheme-clusters -[10]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#diversity-and-inherent-complexity -[11]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#the-unicode-codespace -[12]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#encodings -[13]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#combining-marks -[14]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#and-more -[15]:https://en.wikipedia.org/wiki/Vowel_pointing -[16]:https://en.wikipedia.org/wiki/Devanagari -[17]:https://en.wikipedia.org/wiki/Hangul#Letters -[18]:http://reedbeta.com/blog/programmers-intro-to-unicode/ -[19]:http://reedbeta.com/blog/category/coding/ -[20]:http://reedbeta.com/blog/programmers-intro-to-unicode/#comments -[21]:http://www.unicode.org/versions/latest/ -[22]:http://utf8everywhere.org/ -[23]:https://eev.ee/blog/2015/09/12/dark-corners-of-unicode/ -[24]:http://site.icu-project.org/ -[25]:https://docs.python.org/3/howto/unicode.html -[26]:https://www.google.com/get/noto/ -[27]:http://www.unicode.org/versions/latest/ -[28]:http://www.unicode.org/reports/ -[29]:http://www.unicode.org/notes/ -[30]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#diversity-and-inherent-complexity -[31]:http://linguistics.berkeley.edu/sei/ -[32]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#the-unicode-codespace -[33]:http://unicode.org/cldr/utility/character.jsp?a=A -[34]:http://unicode.org/cldr/utility/character.jsp?a=%CE%B8 -[35]:http://www.unicode.org/reports/tr44/ -[36]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#codespace-allocation -[37]:http://reedbeta.com/blog/programmers-intro-to-unicode/codespace-map.png -[38]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#scripts -[39]:http://reedbeta.com/blog/programmers-intro-to-unicode/script-map.png -[40]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#usage-frequency -[41]:http://reedbeta.com/blog/programmers-intro-to-unicode/heatmap-wiki+tweets.png -[42]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#encodings -[43]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#utf-8 -[44]:http://utf8everywhere.org/ -[45]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#utf-16 -[46]:http://unicode.org/cldr/utility/character.jsp?a=FEFF -[47]:https://en.wikipedia.org/wiki/Byte_order_mark -[48]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#combining-marks -[49]:http://unicode.org/cldr/utility/character.jsp?a=A -[50]:http://unicode.org/cldr/utility/character.jsp?a=0301 -[51]:http://unicode.org/cldr/utility/character.jsp?a=%C3%81 -[52]:http://unicode.org/cldr/utility/character.jsp?a=%E1%BB%87 -[53]:https://eeemo.net/ -[54]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#canonical-equivalence -[55]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#normalization-forms -[56]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#grapheme-clusters -[57]:http://www.unicode.org/reports/tr29/ -[58]:http://blog.emojipedia.org/emoji-zwj-sequences-three-letters-many-possibilities/ -[59]:http://reedbeta.com/blog/programmers-intro-to-unicode/?imm_mid=0ee8ca&cmp=em-prog-na-na-newsltr_20170311#and-more From 73ae42e22357cc6cc64d6bc86736f864a57178a4 Mon Sep 17 00:00:00 2001 From: chenxinlong <237448382@qq.com> Date: Thu, 1 Jun 2017 21:58:10 +0800 Subject: [PATCH 04/17] translating --- ...introduction to Linux s EXT4 filesystem.md | 22 +++++++++---------- 1 file changed, 10 insertions(+), 12 deletions(-) diff --git a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md b/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md index ecb2084da7..7c776ce8d6 100644 --- a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md +++ b/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md @@ -1,26 +1,24 @@ -Translating by chenxinlong An introduction to Linux's EXT4 filesystem ============================================================ -### Take a walk through EXT4's history, features, and optimal use, and learn how it differs from previous iterations of the EXT filesystem. - +### 让我们大概了解一下 EXT4 的历史、特性以及最佳实践来学习它和之前的所有 EXT 文件系统有何不同。 ![An introduction to the EXT4 filesystem](https://opensource.com/sites/default/files/styles/image-full-size/public/images/life/hard_drives.png?itok=yZWyaSO6 "An introduction to the EXT4 filesystem") ->Image credits : [WIlliam][8][ Warby][9]. Modified by [Jason Baker][10]. Creative Commons [BY-SA 2.0][11]. +>图片来自 : [WIlliam][8][ Warby][9]. 由 [Jason Baker][10] 编辑. Creative Commons [BY-SA 2.0][11]. -In previous articles about Linux filesystems, I wrote [an introduction to Linux filesystems][12] and about some higher-level concepts such as [everything is a file][13]. I want to go into more detail about the specifics of the EXT filesystems, but first, let's answer the question, "What is a filesystem?" A filesystem is all of the following: +在之前关于 Linux 文件系统的文章里，我写过一篇 [an introduction to Linux filesystems][12] 和一些更高级的概念例如 [everything is a file][13]. 我想要更深入地了解 EXT 文件系统的特性的详细内容，但是首先让我们来回答一个问题，“什么样才算是一个文件系统 ？” 一个文件系统应该涵盖以下所有点： -1. **Data storage: **The primary function of any filesystem is to be a structured place to store and retrieve data. +1. **数据存储:** 对于任何一个文件系统来说，一个最主要的功能就是能够被当作一个容器结构来存储和恢复数据。 -2. **Namespace: **A naming and organizational methodology that provides rules for naming and structuring data. +2. **命名空间:** 命名空间是一个提供了命名规则和数据结构的用于命名与组织的方法学。 -3. **Security model: **A scheme for defining access rights. +3. **安全模型:** 一个用于定义访问权限的策略。 -4. **API: **System function calls to manipulate filesystem objects like directories and files. +4. **API:** 指的是调用了操作这个系统的对象的系统方法，这些对象诸如目录和文件。 -5. **Implementation: **The software to implement the above. +5. **实现:** 能够实现以上几点的软件。 -This article concentrates on the first item in the list and explores the metadata structures that provide the logical framework for data storage in an EXT filesystem. +本文内容的讨论主要集中于上述几点中的第一项并探索为一个 EXT 文件系统的数据存储提供逻辑框架的元数据结构。 ### EXT filesystem history @@ -261,7 +259,7 @@ David Both - David Both is a Linux and Open Source advocate who resides in Ralei via: https://opensource.com/article/17/5/introduction-ext4-filesystem 作者：[David Both ][a] -译者：[译者ID](https://github.com/chenxinlong) +译者：[chenxinlong](https://github.com/chenxinlong) 校对：[校对者ID](https://github.com/校对者ID) 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 From 6b3161bfd064d19672c7d5c98f6c19460f957ede Mon Sep 17 00:00:00 2001 From: chenxinlong <237448382@qq.com> Date: Fri, 2 Jun 2017 22:16:53 +0800 Subject: [PATCH 05/17] translating --- .../20170525 An introduction to Linux s EXT4 filesystem.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md b/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md index 7c776ce8d6..39081d9de1 100644 --- a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md +++ b/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md @@ -20,9 +20,9 @@ An introduction to Linux's EXT4 filesystem 本文内容的讨论主要集中于上述几点中的第一项并探索为一个 EXT 文件系统的数据存储提供逻辑框架的元数据结构。 -### EXT filesystem history +### EXT 文件系统历史 -Although written for Linux, the EXT filesystem has its roots in the Minix operating system and the Minix filesystem, which predate Linux by about five years, being first released in 1987\. Understanding the EXT4 filesystem is much easier if we look at the history and technical evolution of the EXT filesystem family from its Minix roots. +虽然 EXT 文件系统是为 Linux 编写的，但其真正起源于 Minix 操作系统和 Minix 文件系统，而 Minix 最早发布于 1987，早于 Linux 5 年。如果我们从 EXT 文件系统大家族的 Minix 起源来观察其历史与技术发展那么理解 EXT4 文件系统就会简单得多。 ### Minix @@ -252,7 +252,7 @@ The EXT filesystems have been the default for many Linux distributions for more 作者简介： -David Both - David Both is a Linux and Open Source advocate who resides in Raleigh, North Carolina. He has been in the IT industry for over forty years and taught OS/2 for IBM where he worked for over 20 years. While at IBM, he wrote the first training course for the original IBM PC in 1981. He has taught RHCE classes for Red Hat and has worked at MCI Worldcom, Cisco, and the State of North Carolina. He has been working with Linux and Open Source Software for almost 20 years. +David Both - David Both 是一名 Linux 于开源的贡献者，目前居住在北卡罗莱纳州的罗利。他从事 IT 行业有 40 余年并在 IBM 中从事 OS/2 培训约 20 余年。在 IBM 就职期间，他在 1981 年为最早的 IBM PC 写了一个培训课程。他已经为红帽教授了 RHCE 课程，曾在 MCI Worldcom，思科和北卡罗来纳州工作。 他使用 Linux 和开源软件工作了近 20 年。 ------------------- From a7d455fc0253756433b6243ce947d95e55e19869 Mon Sep 17 00:00:00 2001 From: chenxinlong <237448382@qq.com> Date: Wed, 7 Jun 2017 23:51:05 +0800 Subject: [PATCH 06/17] keep translating --- ...An introduction to Linux s EXT4 filesystem.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md b/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md index 39081d9de1..4067987a85 100644 --- a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md +++ b/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md @@ -26,21 +26,21 @@ An introduction to Linux's EXT4 filesystem ### Minix -When writing the original Linux kernel, Linus Torvalds needed a filesystem but didn't want to write one then. So he simply included the [Minix filesystem][14], which had been written by [Andrew S. Tanenbaum][15] and was a part of Tanenbaum's Minix operating system. [Minix][16] was a Unix-like operating system written for educational purposes. Its code was freely available and appropriately licensed to allow Torvalds to include it in his first version of Linux. +当 Linux Torvalds 在写最初的 Linux 内核的时候，他需要一个文件系统但是他又不想自己写一个。于是他简单地把 [Minix 文件系统][14] 加了进去，这个 Minix 文件系统是由 [Andrew S. Tanenbaum][15] 写的同时也是 Tanenbaum 的 Minix 操作系统的一部分。[Minix][16] 是一个类 Unix 风格的操作系统，最初编写它的原因是用于教育。Minx 的代码是自由可用的且经过适当的许可的，所以 Torvalds 可以把它用 Linux 的最初版本里。 -Minix has the following structures, most of which are located in the partition where the filesystem is generated: +Minix 有以下这些结构，其中的大部分位于生成文件系统的分区中： -* A [**boot sector**][6] in the first sector of the hard drive on which it is installed. The boot block includes a very small boot record and a partition table. +* [**boot 扇区**][6] 是硬盘驱动安装后的第一个扇区。这个 boot 块包含了一个非常小的 boot 记录和一个分区表。 -* The first block in each partition is a **superblock **that contains the metadata that defines the other filesystem structures and locates them on the physical disk assigned to the partition. +* 每一个分区的第一个块都是一个包含了元数据的 **superblock** ，这些元数据定义了其他文件系统的结构并将其定位于物理硬盘的具体分区上。 -* An **inode bitmap block**, which determines which inodes are used and which are free. +* 一个 **inode 位图块** 决定了哪些 inode 是在使用中的，哪一些是未使用的。 -* The **inodes**, which have their own space on the disk. Each inode contains information about one file, including the locations of the data blocks, i.e., zones belonging to the file. +* **inode** 在硬盘上有它们自己的空间。每一个 inode 都包含了一个文件的信息包括其所处的数据块的位置，也就是该文件所处的区域。 -* A **zone bitmap** to keep track of the used and free data zones. +* 一个 **区位图** 用于保持追踪数据区域的使用和未使用情况。 -* A **data zone**, in which the data is actually stored. +* 一个 **数据区**, 这里是数据存储的地方。 For both types of bitmaps, one bit represents one specific data zone or one specific inode. If the bit is zero, the zone or inode is free and available for use, but if the bit is one, the data zone or inode is in use. From 4c0a80c39ef207fa500b0eb1829ddee06a3e718a Mon Sep 17 00:00:00 2001 From: chenxinlong <237448382@qq.com> Date: Sat, 10 Jun 2017 22:36:07 +0800 Subject: [PATCH 07/17] keep updating --- ...70525 An introduction to Linux s EXT4 filesystem.md | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md b/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md index 4067987a85..22cf57325b 100644 --- a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md +++ b/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md @@ -1,7 +1,7 @@ -An introduction to Linux's EXT4 filesystem +Linux 的 EXT4 文件系统简介 ============================================================ -### 让我们大概了解一下 EXT4 的历史、特性以及最佳实践来学习它和之前的所有 EXT 文件系统有何不同。 +### 让我们大概地从 EXT4 的历史、特性以及最佳实践这几个方面来学习它和之前的所有的 EXT 文件系统有何不同。 ![An introduction to the EXT4 filesystem](https://opensource.com/sites/default/files/styles/image-full-size/public/images/life/hard_drives.png?itok=yZWyaSO6 "An introduction to the EXT4 filesystem") >图片来自 : [WIlliam][8][ Warby][9]. 由 [Jason Baker][10] 编辑. Creative Commons [BY-SA 2.0][11]. @@ -42,9 +42,11 @@ Minix 有以下这些结构，其中的大部分位于生成文件系统的分 * 一个 **数据区**, 这里是数据存储的地方。 -For both types of bitmaps, one bit represents one specific data zone or one specific inode. If the bit is zero, the zone or inode is free and available for use, but if the bit is one, the data zone or inode is in use. +对上述了两种位图类型来说，一个 bit 表示一个制定的数据区或者一个指定的 inode. 如果这个 bit 是 0 则表示这个数据区或者这个 inode 是可以使用的，如果是 1 则表示正在使用中。 -What is an [inode][17]? Short for index-node, an inode is a 256-byte block on the disk and stores data about the file. This includes the file's size; the user IDs of the file's user and group owners; the file mode (i.e., the access permissions); and three timestamps specifying the time and date that: the file was last accessed, last modified, and the data in the inode was last modified. +那么，[inode][17] 又是什么呢 ? 就是 index-node (索引节点)的简写。 inode 是位于磁盘上的一个 256 字节的块，用于存储和该 inode 对应的文件的相关数据。这些数据包含了文件的大小、文件的所有者和所属组的用户的 ID、文件模式（即访问权限）以及三个时间戳用于指定：该文件最后的访问时间、该文件的最后修改时间和该 inode 中的数据的最后修改时间。 + +The inode also contains data that points to the location of the file's data on the hard drive. In Minix and the EXT1-3 filesystems, this is a list of data zones or blocks. The Minix filesystem inodes supported nine data blocks, seven direct and two indirect. If you'd like to learn more, there is an excellent PDF with a detailed description of the [Minix filesystem structure][18] and a quick overview of the [inode pointer structure][19] on Wikipedia. The inode also contains data that points to the location of the file's data on the hard drive. In Minix and the EXT1-3 filesystems, this is a list of data zones or blocks. The Minix filesystem inodes supported nine data blocks, seven direct and two indirect. If you'd like to learn more, there is an excellent PDF with a detailed description of the [Minix filesystem structure][18] and a quick overview of the [inode pointer structure][19] on Wikipedia. From b59baa18d433d70ef7ea8210ac9865a1d3e03647 Mon Sep 17 00:00:00 2001 From: chenxinlong <237448382@qq.com> Date: Sat, 10 Jun 2017 23:15:27 +0800 Subject: [PATCH 08/17] keep updating --- ...525 An introduction to Linux s EXT4 filesystem.md | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md b/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md index 22cf57325b..e281660fa5 100644 --- a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md +++ b/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md @@ -46,21 +46,19 @@ Minix 有以下这些结构，其中的大部分位于生成文件系统的分 那么，[inode][17] 又是什么呢 ? 就是 index-node (索引节点)的简写。 inode 是位于磁盘上的一个 256 字节的块，用于存储和该 inode 对应的文件的相关数据。这些数据包含了文件的大小、文件的所有者和所属组的用户的 ID、文件模式（即访问权限）以及三个时间戳用于指定：该文件最后的访问时间、该文件的最后修改时间和该 inode 中的数据的最后修改时间。 -The inode also contains data that points to the location of the file's data on the hard drive. In Minix and the EXT1-3 filesystems, this is a list of data zones or blocks. The Minix filesystem inodes supported nine data blocks, seven direct and two indirect. If you'd like to learn more, there is an excellent PDF with a detailed description of the [Minix filesystem structure][18] and a quick overview of the [inode pointer structure][19] on Wikipedia. - -The inode also contains data that points to the location of the file's data on the hard drive. In Minix and the EXT1-3 filesystems, this is a list of data zones or blocks. The Minix filesystem inodes supported nine data blocks, seven direct and two indirect. If you'd like to learn more, there is an excellent PDF with a detailed description of the [Minix filesystem structure][18] and a quick overview of the [inode pointer structure][19] on Wikipedia. +同时，这个 inode 还包含了指向了其所对应的文件的数据在硬盘中的位置。在 Minix 和 EXT1-3 文件系统中，inode 表示的是一系列的的数据区和块。Minix 文件系统的 inode 支持 9 个数据块包括 7 个直接数据块和 2 个间接数据块。如果你想要更深入的了解，这里有一个优秀的 PDF 详细地描述了 [Minix 文件系统街头][18] 。同时你也可以在维基百科上对 [inode 指针结构][19] 做一个快速的浏览。 ### EXT -The original [EXT filesystem][20] (Extended) was written by [Rémy Card][21] and released with Linux in 1992 to overcome some size limitations of the Minix filesystem. The primary structural changes were to the metadata of the filesystem, which was based on the Unix filesystem (UFS), which is also known as the Berkeley Fast File System (FFS). I found very little published information about the EXT filesystem that can be verified, apparently because it had significant problems and was quickly superseded by the EXT2 filesystem. +原生的 [EXT 文件系统][20] (指经过扩展的) 是由 [Rémy Card][21] 编写并于 1992 年与 Linux 一同发行。主要是为了克服 Minix 文件系统中的一些文件大小限制的问题。其中，最主要的结构变化就是文件系统中的元数据。它基于 Unix 文件系统 （UFS），也被称为伯克利快速文件系统（FFS）。我发现只有很少一部分关于 EXT 文件系统的发行信息是可以被验证的，显然这是因为其存在着严重的问题并且它很快地被 EXT2 文件系统取代了。 ### EXT2 -The [EXT2 filesystem][22] was quite successful. It was used in Linux distributions for many years, and it was the first filesystem I encountered when I started using Red Hat Linux 5.0 back in about 1997\. The EXT2 filesystem has essentially the same metadata structures as the EXT filesystem, however EXT2 is more forward-looking, in that a lot of disk space is left between the metadata structures for future use. +[EXT2 文件系统][22] 就相当地成功，它在 Linux 发行版中存活了多年。它是我在 1997 年开始使用 Red Hat Linux 时认识的第一个文件系统。实际上，EXT2 文件系统有着和 EXT 文件系统基本相同的元数据结构。然而 EXT2 更高瞻远瞩，因为其元数据结构之间留有很多磁盘空间供将来使用。 -Like Minix, EXT2 has a [boot sector][23] in the first sector of the hard drive on which it is installed, which includes a very small boot record and a partition table. Then there is some reserved space after the boot sector, which spans the space between the boot record and the first partition on the hard drive that is usually on the next cylinder boundary. [GRUB2][24]—and possibly GRUB1—uses this space for part of its boot code. +和 Minix 类似，EXT2 也有一个[boot 扇区][23] ，它是硬盘驱动安装后的第一个扇区。它包含了少量的 boot 记录和一个分区表。接着 boot 扇区之后是一些保留的空间，它跨越引导记录和通常位于下一个柱面的硬盘驱动器上的第一个分区之间的空间。 [GRUB2] [24] - 也可能是GRUB1 - 将此空间用于其部分启动代码。 -The space in each EXT2 partition is divided into cylinder groups that allow for more granular management of the data space. In my experience, the group size usually amounts to about 8MB. Figure 1, below, shows the basic structure of a cylinder group. The data allocation unit in a cylinder is the block, which is usually 4K in size. +每个 EXT2 分区中的空间分为各柱面组，它允许更精细地管理数据空间。 根据我的经验，每一组大小通常约为8MB。 下面的图1显示了一个柱面组的基本结构。 柱面中的数据分配单元是块，通常大小为4K。 ![cylindergroup-01_1.png](https://opensource.com/sites/default/files/images/life-uploads/cylindergroup-01_1.png) From b95e22f886fbe9189c8d46e5b2e6012e7b478750 Mon Sep 17 00:00:00 2001 From: chenxinlong <237448382@qq.com> Date: Wed, 14 Jun 2017 22:47:58 +0800 Subject: [PATCH 09/17] keep updating --- ...20170525 An introduction to Linux s EXT4 filesystem.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md b/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md index e281660fa5..916943c3e1 100644 --- a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md +++ b/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md @@ -62,11 +62,11 @@ Minix 有以下这些结构，其中的大部分位于生成文件系统的分 ![cylindergroup-01_1.png](https://opensource.com/sites/default/files/images/life-uploads/cylindergroup-01_1.png) -Figure 1: The structure of a cylinder group in the EXT filesystems +Figure 1: EXT 文件系统中的柱面组的结构 -The first block in the cylinder group is a superblock, which contains the metadata that defines the other filesystem structures and locates them on the physical disk. Some of the additional groups in the partition will have backup superblocks, but not all. A damaged superblock can be replaced by using a disk utility such as **dd** to copy the contents of a backup superblock to the primary superblock. It does not happen often, but once, many years ago, I had a damaged superblock, and I was able to restore its contents using one of the backup superblocks. Fortunately, I had been foresighted and used the **dumpe2fs** command to dump the descriptor information of the partitions on my system. +柱面组中的第一个块是一个超级块，它包含了一个定义了其他文件系统的结构并将其定位于物理硬盘的具体分区上的元数据。分区中有一些柱面组还会有备用超级块，但并不是所有的柱面组都有。我们还可以使用例如 **dd** 等磁盘工具来拷贝备用超级块的内容到主超级块上以达到更换损坏超级块的目的。虽然这种情况不会经常发生，但是在几年前我的一个超级块损坏了，我就是用这种方法来修复的。幸好，我很有先见之明地使用了 **dumpe2fs** 命令来备份了我的分区描述符信息到我的系统上。 -Following is the partial output from the **dumpe2fs** command. It shows the metadata contained in the superblock, as well as data about each of the first two cylinder groups in the filesystem. +以下是 **dumpe2fs** 命令的一部分输出。这部分输出主要是超级块上包含的一些元数据，同时也是文件系统上的前两个柱面组的数据。 ``` # dumpe2fs /dev/sda1 @@ -150,7 +150,7 @@ Group 3: (Blocks 98304-131071) ``` -Each cylinder group has its own inode bitmap that is used to determine which inodes are used and which are free within that group. The inodes have their own space in each group. Each inode contains information about one file, including the locations of the data blocks belonging to the file. The block bitmap keeps track of the used and free data blocks within the filesystem. Notice that there is a great deal of data about the filesystem in the output shown above. On very large filesystems the group data can run to hundreds of pages in length. The group metadata includes a listing of all of the free data blocks in the group. +每一个柱面组都有自己的 inode 位图用于判定该柱面组中的哪些 inode 是使用中的而哪些又是未被使用的。每一个柱面组的 inode 都有它们自己的空间。每一个 inode 都包含了对应的文件的相关信息，包括其位于该文件的数据块中的位置。The block bitmap keeps track of the used and free data blocks within the filesystem. Notice that there is a great deal of data about the filesystem in the output shown above. On very large filesystems the group data can run to hundreds of pages in length. The group metadata includes a listing of all of the free data blocks in the group. The EXT filesystem implemented data-allocation strategies that ensured minimal file fragmentation. Reducing fragmentation improved filesystem performance. Those strategies are described below, in the section on EXT4. From 5d27fb8eec6ef60d891b93d64914d414b274a0af Mon Sep 17 00:00:00 2001 From: chenxinlong <237448382@qq.com> Date: Sat, 17 Jun 2017 11:43:07 +0800 Subject: [PATCH 10/17] keep updating --- ...5 An introduction to Linux s EXT4 filesystem.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md b/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md index 916943c3e1..2f56c1ad7c 100644 --- a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md +++ b/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md @@ -150,17 +150,17 @@ Group 3: (Blocks 98304-131071) ``` -每一个柱面组都有自己的 inode 位图用于判定该柱面组中的哪些 inode 是使用中的而哪些又是未被使用的。每一个柱面组的 inode 都有它们自己的空间。每一个 inode 都包含了对应的文件的相关信息，包括其位于该文件的数据块中的位置。The block bitmap keeps track of the used and free data blocks within the filesystem. Notice that there is a great deal of data about the filesystem in the output shown above. On very large filesystems the group data can run to hundreds of pages in length. The group metadata includes a listing of all of the free data blocks in the group. +每一个柱面组都有自己的 inode 位图用于判定该柱面组中的哪些 inode 是使用中的而哪些又是未被使用的。每一个柱面组的 inode 都有它们自己的空间。每一个 inode 都包含了对应的文件的相关信息，包括其位于该文件的数据块中的位置。这个块位图纪录了文件系统中的使用中和非使用中的数据块。请注意，在上面的输出中有大量关于文件系统的数据。在非常大的文件系统上，组数据可以运行到数百页的长度。 组元数据包括组中所有空闲数据块的列表。 -The EXT filesystem implemented data-allocation strategies that ensured minimal file fragmentation. Reducing fragmentation improved filesystem performance. Those strategies are described below, in the section on EXT4. +EXT 文件系统实现了数据分配策略以确保产生最少的文件碎片。减少文件碎片可以提高文件系统的性能。这些策略会在下面的 EXT4 中描述到。 -The biggest problem with the EXT2 filesystem, which I encountered on some occasions, was that it could take many hours to recover after a crash because the **fsck** (file system check) program took a very long time to locate and correct any inconsistencies in the filesystem. It once took over 28 hours on one of my computers to fully recover a disk upon reboot after a crash—and that was when disks were measured in the low hundreds of megabytes in size. +我所遇见的关于 EXT2 文件系统最大的问题是 **fsck** (文件系统检查) 程序这一环节占用了很长一段时间来定位和校准文件系统中的所有不一致性导致其共花费了数个小时来修复一个崩溃。有一次我的其中一台电脑共花费了 28 个小时在一次崩溃后重新启动时恢复磁盘上，并且是在磁盘被检测量在几百兆字节大小的情况下。 ### EXT3 -The [EXT3 filesystem][25] had the singular objective of overcoming the massive amounts of time that the **fsck** program required to fully recover a disk structure damaged by an improper shutdown that occurred during a file-update operation. The only addition to the EXT filesystem was the [journal][26], which records in advance the changes that will be performed to the filesystem. The rest of the disk structure is the same as it was in EXT2. +[EXT3 文件系统][25] 具有克服 **fsck** 程序需要完全恢复在文件更新操作期间发生的不正确关机损坏的磁盘结构所需的大量时间的单一目标。EXT 文件系统的唯一新增是 [日志][26]，它将提前记录将对文件系统执行的更改。 磁盘结构的其余部分与 EXT2 中的相同。 -Instead of writing data to the disk's data areas directly, as in previous versions, the journal in EXT3 writes file data, along with its metadata, to a specified area on the disk. Once the data is safely on the hard drive, it can be merged in or appended to the target file with almost zero chance of losing data. As this data is committed to the data area of the disk, the journal is updated so that the filesystem will remain in a consistent state in the event of a system failure before all the data in the journal is committed. On the next boot, the filesystem will be checked for inconsistencies, and data remaining in the journal will then be committed to the data areas of the disk to complete the updates to the target file. +作为一个先前的版本，除了直接写入数据到磁盘的数据区域外，EXT3 的日志在写入元数据时同时也写入文件数据到磁盘上的一个指定数据区域。一旦这些数据安全地到达硬盘，它就可以几乎零丢失率地被合并或者被追加到目标文件。当这些数据被提交到磁盘上的数据区域上，这些日志就会随即更新，这样在系统发生故障之前，文件系统将保持一致状态，才能提交日志中的所有数据。在下次启动时，将检查文件系统的不一致性，然后将日志中保留的数据提交到磁盘的数据区，以完成对目标文件的更新。 Journaling does reduce data-write performance, however there are three options available for the journal that allow the user to choose between performance and data integrity and safety. My personal preference is on the side of safety because my environments do not require heavy disk-write activity. @@ -244,9 +244,9 @@ Due to the low amount of fragmentation on most EXT filesystems, it is not necess If it becomes necessary to perform a complete defragmentation on an EXT filesystem, there is only one method that will work reliably. You must move all the files from the filesystem to be defragmented, ensuring that they are deleted after being safely copied to another location. If possible, you could then increase the size of the filesystem to help reduce future fragmentation. Then copy the files back onto the target filesystem. Even this does not guarantee that all the files will be completely defragmented. -### Conclusions +### 总结 -The EXT filesystems have been the default for many Linux distributions for more than 20 years. They offer stability, high capacity, reliability, and performance while requiring minimal maintenance. I have tried other filesystems but always return to EXT. Every place I have worked with Linux has used the EXT filesystems and found them suitable for all the mainstream loads used on them. Without a doubt, the EXT4 filesystem should be used for most Linux systems unless there is a compelling reason to use another filesystem. +EXT 文件系统在一些 Linux 发行版本上作为默认文件系统已经超过二十多年了。它们用最少的维护代价提供了稳定性、高可用性、可靠性和其他各种表现。我尝试过一些其它的文件系统但最终都还是回归到 EXT。每一个我在工作中使用到 Linux 的地方都使用到了 EXT 文件系统，同时发现了它们适用于任何主流的负载。毫无疑问，EXT4 文件系统应该被用于大部分的 Linux 文件系统上，除非我们有明显的使用其它文件系统的理由。 -------------------------------------------------------------------------------- From 465667c284d79ce806c9038e5115969f8c9cf7c7 Mon Sep 17 00:00:00 2001 From: chenxinlong <237448382@qq.com> Date: Sat, 24 Jun 2017 18:56:26 +0800 Subject: [PATCH 11/17] add content --- ...introduction to Linux s EXT4 filesystem.md | 40 +++++++++---------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md b/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md index 2f56c1ad7c..850c109e7e 100644 --- a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md +++ b/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md @@ -160,55 +160,55 @@ EXT 文件系统实现了数据分配策略以确保产生最少的文件碎片 [EXT3 文件系统][25] 具有克服 **fsck** 程序需要完全恢复在文件更新操作期间发生的不正确关机损坏的磁盘结构所需的大量时间的单一目标。EXT 文件系统的唯一新增是 [日志][26]，它将提前记录将对文件系统执行的更改。 磁盘结构的其余部分与 EXT2 中的相同。 -作为一个先前的版本，除了直接写入数据到磁盘的数据区域外，EXT3 的日志在写入元数据时同时也写入文件数据到磁盘上的一个指定数据区域。一旦这些数据安全地到达硬盘，它就可以几乎零丢失率地被合并或者被追加到目标文件。当这些数据被提交到磁盘上的数据区域上，这些日志就会随即更新，这样在系统发生故障之前，文件系统将保持一致状态，才能提交日志中的所有数据。在下次启动时，将检查文件系统的不一致性，然后将日志中保留的数据提交到磁盘的数据区，以完成对目标文件的更新。 +作为一个先前的版本，除了直接写入数据到磁盘的数据区域外，EXT3 的日志在写入元数据时同时会也写入文件数据到磁盘上的一个指定数据区域。一旦这些数据安全地到达硬盘，它就可以几乎零丢失率地被合并或者被追加到目标文件。当这些数据被提交到磁盘上的数据区域上，这些日志就会随即更新，这样在系统发生故障之前，文件系统将保持一致状态，才能提交日志中的所有数据。在下次启动时，将检查文件系统的不一致性，然后将日志中保留的数据提交到磁盘的数据区，以完成对目标文件的更新。 -Journaling does reduce data-write performance, however there are three options available for the journal that allow the user to choose between performance and data integrity and safety. My personal preference is on the side of safety because my environments do not require heavy disk-write activity. +日记功能确实降低了数据写入性能，但是有三个可用于日志的选项，允许用户在性能和数据完整性和安全性之间进行选择。 我的个人更偏向于选择安全性，因为我的环境不需要大量的磁盘写入活动。 -The journaling function reduces the time required to check the hard drive for inconsistencies after a failure from hours (or even days) to mere minutes, at the most. I have had many issues over the years that have crashed my systems. The details could fill another article, but suffice it to say that most were self-inflicted, like kicking out a power plug. Fortunately, the EXT journaling filesystems have reduced that bootup recovery time to two or three minutes. In addition, I have never had a problem with lost data since I started using EXT3 with journaling. +日志功能减少了在从几小时（甚至几天）到几分钟之间的失败后检查硬盘驱动器所需的时间。 多年来，我遇到了很多问题导致了我的系统崩溃。 要详细说的话恐怕还得再写一篇文章，但这足以说明大多数是我自己造成的，就比如不小心踢掉一个电源插头。 幸运的是，EXT日志文件系统将启动恢复时间缩短到两三分钟。 此外，自从我开始使用带日志记录的EXT3，我从来没有遇到丢失数据的问题。 -The journaling feature of EXT3 can be turned off and it then functions as an EXT2 filesystem. The journal itself still exists, empty and unused. Simply remount the partition with the mount command using the type parameter to specify EXT2\. You may be able to do this from the command line, depending upon which filesystem you are working with, but you can change the type specifier in the **/etc/fstab** file and then reboot. I strongly recommend against mounting an EXT3 filesystem as EXT2 because of the additional potential for lost data and extended recovery times. +EXT3 的日志功能可以关闭，然后作为 EXT2 文件系统。 该日志本身仍然是存在的，只是状态为空且未使用。 只需使用类型参数使用 mount 命令来 remount 到分区即可指定EXT2 \。 你可以从命令行执行此操作，但是具体还是取决于你正在使用的文件系统，但你可以更改 **/ etc / fstab** 文件中的类型说明符，然后重新启动。 我强烈建议不要将 EXT3文件系统安装为 EXT2 ，因为这会具有丢失数据和增加恢复时间的潜在可能性。 -An existing EXT2 filesystem can be upgraded to EXT3 with the addition of a journal using the following command. +EXT2 文件系统可以使用如下命令来通过日志升级到 EXT3 。 ``` tune2fs -j /dev/sda1 ``` -Where **/dev/sda1** is the drive and partition identifier. Be sure to change the file type specifier in **/etc/fstab** and remount the partition or reboot the system to have the change take effect. + **/dev/sda1** 表示驱动和分区的标识符。同时要注意修改 **/etc/fstab** 中的文件类型标识符并 remount 分区或者重启系统以确保修改生效。 ### EXT4 -The [EXT4 filesystem][27] primarily improves performance, reliability, and capacity. To improve reliability, metadata and journal checksums were added. To meet various mission-critical requirements, the filesystem timestamps were improved with the addition of intervals down to nanoseconds. The addition of two high-order bits in the timestamp field defers the [Year 2038 problem][28] until 2446—for EXT4 filesystems, at least. +[EXT4 filesystem][27]主要提高了性能、可靠性和容量。位了提高可靠性，它新增了元数据和日志校验和。同时位了满足各种关键任务要求，文件系统新增了纳秒级别的时间戳。在时间戳字段中添加两个高位来延迟时间戳的 [2038 年的问题][28] ，在 EXT4 文件系统至少可达到 2446 年。 -In EXT4, data allocation was changed from fixed blocks to extents. An extent is described by its starting and ending place on the hard drive. This makes it possible to describe very long, physically contiguous files in a single inode pointer entry, which can significantly reduce the number of pointers required to describe the location of all the data in larger files. Other allocation strategies have been implemented in EXT4 to further reduce fragmentation. +在 EXT4 中，数据分配从固定块更改为盘区，盘区由硬盘驱动器上的开始和结束位置来描述。这使得可以在单个 inode 指针条目中描述非常长的物理连续的文件，这可以显着减少描述大文件中所有数据的位置所需的指针数。 EXT4 中已经实施了其他分配策略，以进一步减少碎片化。 -EXT4 reduces fragmentation by scattering newly created files across the disk so that they are not bunched up in one location at the beginning of the disk, as many early PC filesystems did. The file-allocation algorithms attempt to spread the files as evenly as possible among the cylinder groups and, when fragmentation is necessary, to keep the discontinuous file extents as close as possible to others in the same file to minimize head seek and rotational latency as much as possible. Additional strategies are used to pre-allocate extra disk space when a new file is created or when an existing file is extended. This helps to ensure that extending the file will not automatically result in its becoming fragmented. New files are never allocated immediately after existing files, which also prevents fragmentation of the existing files. +EXT4 通过将新创建的文件分散在磁盘上，从而使其不会全部聚集在磁盘起始位置，就像早期的PC文件系统一样，减少了碎片。文件分配算法尝试在柱面组中尽可能均匀地扩展文件，并且当需要分段时，要使不连续文件扩展区尽可能靠近同一文件中的其他文件，以尽可能减少头部搜索和旋转等待时间尽可能的当创建新文件或扩展现有文件时，使用其他策略来预分配额外的磁盘空间。这有助于确保扩展文件不会自动导致其分段。新文件不会在现有文件之后立即分配，这也可以防止现有文件的碎片化。 -Aside from the actual location of the data on the disk, EXT4 uses functional strategies, such as delayed allocation, to allow the filesystem to collect all the data being written to the disk before allocating space to it. This can improve the likelihood that the data space will be contiguous. +除了磁盘上数据的实际位置外，EXT4 使用诸如延迟分配的功能策略，以允许文件系统在分配空间之前收集正在写入磁盘的所有数据。这可以提高数据空间将是连续的可能性。 -Older EXT filesystems, such as EXT2 and EXT3, can be mounted as EXT4 to make some minor performance gains. Unfortunately, this requires turning off some of the important new features of EXT4, so I recommend against this. +较旧的EXT文件系统（如 EXT2 和 EXT3）可以作为 EXT4 进行 mount ，以使其性能获得较小的提升。不幸的是，这需要关闭 EXT4 的一些重要的新功能，所以我建议不要这样做。 -EXT4 has been the default filesystem for Fedora since Fedora 14\. An EXT3 filesystem can be upgraded to EXT4 using the [procedure ][29]described in the Fedora documentation, however its performance will still suffer due to residual EXT3 metadata structures. The best method for upgrading to EXT4 from EXT3 is to back up all the data on the target filesystem partition, use the **mkfs** command to write an empty EXT4 filesystem to the partition, and then restore all the data from the backup. +自 Fedora 14 以来，EXT4 一直是 Fedora 的默认文件系统。我们可以使用 Fedora 文档中描述的 [procedure ][29] 将EXT3文件系统升级到EXT4，但是由于之前仍然存留d的 EXT3 元数据结构，它的性能仍将受到影响。从 EXT3 升级到 EXT4 的最佳方法是备份目标文件系统分区上的所有数据，使用 **mkfs** 命令将空EXT4文件系统写入分区，然后从备份中恢复所有数据。 ### Inode -The inode, described previously, is a key component of the metadata in EXT filesystems. Figure 2 shows the relationship between the inode and the data stored on the hard drive. This diagram is the directory and inode for a single file which, in this case, may be highly fragmented. The EXT filesystems work actively to reduce fragmentation, so it is very unlikely you will ever see a file with this many indirect data blocks or extents. In fact, as you will see below, fragmentation is extremely low in EXT filesystems, so most inodes will use only one or two direct data pointers and none of the indirect pointers. +以前描述的 inode 是EXT文件系统中的元数据的关键组件。 图 2 显示了 inode 和存储在硬盘驱动器上的数据之间的关系。 该图是单个文件的目录和 inode，在这种情况下，可能会产生高度碎片。 EXT 文件系统可以积极地减少碎片，所以不太可能会看到有这么多间接数据块或扩展盘的文件。 实际上，如下所示，EXT文件系统中的碎片非常低，所以大多数 inode 只使用一个或两个直接数据指针，也不使用间接指针。 ![inodesanddataallocation-01_0.png](https://opensource.com/sites/default/files/images/life-uploads/inodesanddataallocation-01_0.png) -Figure 2: The inode stores information about each file and enables the EXT filesystem to locate all data belonging to it. +图 2 ：inode 存储有关每个文件的信息，并使 EXT 文件系统能够查找属于它的所有数据。 -The inode does not contain the name of the file. Access to a file is via the directory entry, which itself is the name of the file and contains a pointer to the inode. The value of that pointer is the inode number. Each inode in a filesystem has a unique ID number, but inodes in other filesystems on the same computer (and even the same hard drive) can have the same inode number. This has implications for [links][30], and this discussion is beyond the scope of this article. +inode 不包含文件的名称。通过目录条目访问文件，目录条目本身是文件的名称，并包含指向 inode 的指针。该指针的值是 inode 号。文件系统中的每个 inode 都具有唯一的 ID 号，但同一台计算机上的其他文件系统（甚至相同的硬盘驱动器）中的 inode 可以具有相同的 inode 号。这对[links][30] 存在影响，但是这个讨论超出了本文的范围。 -The inode contains the metadata about the file, including its type and permissions as well as its size. The inode also contains space for 15 pointers that describe the location and length of data blocks or extents in the data portion of the cylinder group. Twelve of the pointers provide direct access to the data extents and should be sufficient to handle most files. However, for files that have significant fragmentation, it becomes necessary to have some additional capabilities in the form of indirect nodes. Technically these are not really inodes, so I use the term "node" here for convenience. +inod e包含有关该文件的元数据，包括其类型和权限以及其大小。 inode 还包含 15 个指针的空格，用于描述柱面组数据部分中数据块或扩展区的位置和长度。十二个指针提供对数据扩展区的直接访问，并且应该足以处理大多数文件。然而，对于具有重大分段的文件，有必要以间接节点的形式具有一些附加功能。从技术上讲，这些不是真正的节点，所以我在这里使用这个术语“节点”来方便。 -An indirect node is a normal data block in the filesystem that is used only for describing data and not for storage of metadata, thus more than 15 entries can be supported. For example, a block size of 4K can support 512 4-byte indirect nodes, allowing **12 (direct) + 512 (indirect) = 524** extents for a single file. Double and triple indirect node support is also supported, but most of us are unlikely to encounter files requiring that many extents. +间接节点是文件系统中的正常数据块，它仅用于描述数据而不用于存储元数据，因此可以支持超过 15 个条目。例如，4K 的块大小可以支持 512 个 4 字节间接节点，允许单个文件的 **12（直接）+ 512（间接）= 524** 范围。还支持双重和三重间接节点支持，但我们大多数人不太可能遇到需要许多扩展的文件。 -### Data fragmentation +### 数据碎片 -For many older PC filesystems, such as FAT (and all its variants) and NTFS, fragmentation has been a significant problem resulting in degraded disk performance. Defragmentation became an industry in itself with different brands of defragmentation software that ranged from very effective to only marginally so. +对于许多较旧的 PC 文件系统，如 FAT（及其所有变体）和 NTFS，碎片一直是导致磁盘性能下降的重大问题。 碎片整理对于其本身和一些专门的整理软件来说已经称为了一项专门的工程，其效果范围从非常有效到仅仅是微乎其微。 -Linux's extended filesystems use data-allocation strategies that help to minimize fragmentation of files on the hard drive and reduce the effects of fragmentation when it does occur. You can use the **fsck** command on EXT filesystems to check the total filesystem fragmentation. The following example checks the home directory of my main workstation, which was only 1.5% fragmented. Be sure to use the **-n** parameter, because it prevents **fsck** from taking any action on the scanned filesystem. +Linux 的扩展文件系统使用数据分配策略，有助于最小化硬盘驱动器上的文件碎片，并在发生碎片时减少碎片的影响。 你可以使用 EXT 文件系统上的 **fsck** 命令检查文件系统的整体碎片。 以下示例检查主工作站的主目录，只有 1.5％ 的碎片。 确保使用 **- n** 参数，因为它会阻止 **fsck** 对扫描文件系统采取的任何操作。 ``` fsck -fn /dev/mapper/vg_01-home From 810864d3a93348133e5bd3ed7288d3a4bd0e353a Mon Sep 17 00:00:00 2001 From: chenxinlong <237448382@qq.com> Date: Sat, 24 Jun 2017 23:16:21 +0800 Subject: [PATCH 12/17] finished translating --- ...n introduction to Linux s EXT4 filesystem.md | 17 +++++++++-------- 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md b/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md index 850c109e7e..3bbd63ff73 100644 --- a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md +++ b/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md @@ -214,9 +214,10 @@ Linux 的扩展文件系统使用数据分配策略，有助于最小化硬盘 fsck -fn /dev/mapper/vg_01-home ``` -I once performed some theoretical calculations to determine whether disk defragmentation might result in any noticeable performance improvement. While I did make some assumptions, the disk performance data I used were from a new 300GB, Western Digital hard drive with a 2.0ms track-to-track seek time. The number of files in this example was the actual number that existed in the filesystem on the day I did the calculation. I did assume that a fairly large amount of the fragmented files (20%) would be touched each day. +我曾经进行过一些理论计算，以确定磁盘碎片整理是否会导致任何明显的性能提升。 虽然我做了一些假设，我使用的磁盘性能数据来自一个新的 300GB 的西部数字硬盘驱动器，具有 2.0ms 的追踪到追踪时间。 此示例中的文件数是在计算当天文件系统中存在的实际数。 我假设有相当大量的碎片文件（约 20％）每天都会被触动。 | **Total files** | **271,794** | +|--|--| | % fragmentation | 5.00% | | Discontinuities | 13,590 | |   |   | @@ -230,19 +231,19 @@ I once performed some theoretical calculations to determine whether disk defragm | Total additional seek time per day | 5.44 sec | |   | 0.091 min | -Table 1: The theoretical effects of fragmentation on disk performance +表 1: 碎片对磁盘性能的理论影响 -I have done two calculations for the total additional seek time per day, one based on the track-to-track seek time, which is the more likely scenario for most files due to the EXT file allocation strategies, and one for the average seek time, which I assumed would make a fair worst-case scenario. +我对每天的全部追加寻道时间进行了两次计算，一次是单磁道寻道时间，这是由于EXT文件分配策略而导致大多数文件的可能性更大的情况，一个是平均搜索时间，我认为这将是一个公平的最坏情况。 -As you can see from Table 1, the impact of fragmentation on a modern EXT filesystem with a hard drive of even modest performance would be minimal and negligible for the vast majority of applications. You can plug the numbers from your environment into your own similar spreadsheet to see what you might expect in the way of performance impact. This type of calculation most likely will not represent actual performance, but it can provide a bit of insight into fragmentation and its theoretical impact on a system. +从表 1 可以看出，对绝大多数应用程序而言，碎片化对具有甚至适度性能的硬盘驱动器的现代EXT文件系统的影响将是微乎其微的。您可以将您的环境中的数字插入到您自己的类似电子表格中，以了解你对性能影响的期望。这种类型的计算不一定能够代表实际的性能，但它可以提供一些洞察碎片化及其对系统的理论影响。 -Most of my partitions are around 1.5% or 1.6% fragmented; I do have one that is 3.3% fragmented but that is a large, 128GB filesystem with fewer than 100 very large ISO image files; I've had to expand the partition several times over the years as it got too full. +我的大部分分区的碎片率都在 1.5％ 左右或 1.6％，我有一个分区有 3.3％ 的碎片，但是这是一个大的 128GB 文件系统，具有少于100 个非常大的 ISO 映像文件; 多年来，我不得不扩张分区，因为它已经太满了。 -That is not to say that some application environments don't require greater assurance of even less fragmentation. The EXT filesystem can be tuned with care by a knowledgeable admin who can adjust the parameters to compensate for specific workload types. This can be done when the filesystem is created or later using the **tune2fs** command. The results of each tuning change should be tested, meticulously recorded, and analyzed to ensure optimum performance for the target environment. In the worst case, where performance cannot be improved to desired levels, other filesystem types are available that may be more suitable for a particular workload. And remember that it is common to mix filesystem types on a single host system to match the load placed on each filesystem. +这并不是说一些应用的环境不需要更多的保证，甚至更少的碎片。 EXT 文件系统可以由有经验和知识的管理员小心调整，管理员可以调整参数以抵消特定的工作负载类型。这个工作可以在文件系统创建的时候或稍后使用 **tune2fs** 命令时完成。每一次调整变化的结果应进行测试，精心的记录和分析，以确保目标环境的最佳性能。在最坏的情况下，如果性能不能提高到期望的水平，则其他文件系统类型可能更适合特定的工作负载。并记住，在单个主机系统上使用混合文件系统类型以匹配放在每个文件系统上的负载是常见的。 -Due to the low amount of fragmentation on most EXT filesystems, it is not necessary to defragment. In any event, there is no safe defragmentation tool for EXT filesystems. There are a few tools that allow you to check the fragmentation of an individual file or the fragmentation of the remaining free space in a filesystem. There is one tool, **e4defrag**, which will defragment a file, directory, or filesystem as much as the remaining free space will allow. As its name implies, it only works on files in an EXT4 filesystem, and it does have some limitations. +由于大多数 EXT 文件系统的碎片数量较少，因此无需进行碎片整理。在任何情况下，EXT 文件系统都没有安全的碎片整理工具。有几个工具允许你检查单个文件的碎片或文件系统中剩余可用空间的碎片。有一个工具，**e4defrag**，它将对剩余可用空间允许的文件，目录或文件系统进行碎片整理。顾名思义，它只适用于 EXT4 文件系统中的文件，并且它还有一其它的些限制。 -If it becomes necessary to perform a complete defragmentation on an EXT filesystem, there is only one method that will work reliably. You must move all the files from the filesystem to be defragmented, ensuring that they are deleted after being safely copied to another location. If possible, you could then increase the size of the filesystem to help reduce future fragmentation. Then copy the files back onto the target filesystem. Even this does not guarantee that all the files will be completely defragmented. +如果有必要在 EXT 文件系统上执行完整的碎片整理，则只有一种方法能够可靠地工作。你必须将文件系统中的所有要进行碎片整理的文件在确保在安全复制到其他位置后将其删除。如果可能，你可以增加文件系统的大小，以帮助减少将来的碎片。然后将文件复制回目标文件系统。但是其实即使这样也不能保证所有文件都被完全碎片整理。 ### 总结 From 527b9ec0155272a708bdc1f25300fbda4aca6194 Mon Sep 17 00:00:00 2001 From: chenxinlong <237448382@qq.com> Date: Sat, 24 Jun 2017 23:19:50 +0800 Subject: [PATCH 13/17] move to translated --- ...introduction to Linux s EXT4 filesystem.md | 301 ------------------ 1 file changed, 301 deletions(-) delete mode 100644 sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md diff --git a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md b/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md deleted file mode 100644 index 3bbd63ff73..0000000000 --- a/sources/tech/20170525 An introduction to Linux s EXT4 filesystem.md +++ /dev/null @@ -1,301 +0,0 @@ -Linux 的 EXT4 文件系统简介 -============================================================ - -### 让我们大概地从 EXT4 的历史、特性以及最佳实践这几个方面来学习它和之前的所有的 EXT 文件系统有何不同。 - -![An introduction to the EXT4 filesystem](https://opensource.com/sites/default/files/styles/image-full-size/public/images/life/hard_drives.png?itok=yZWyaSO6 "An introduction to the EXT4 filesystem") ->图片来自 : [WIlliam][8][ Warby][9]. 由 [Jason Baker][10] 编辑. Creative Commons [BY-SA 2.0][11]. - -在之前关于 Linux 文件系统的文章里，我写过一篇 [an introduction to Linux filesystems][12] 和一些更高级的概念例如 [everything is a file][13]. 我想要更深入地了解 EXT 文件系统的特性的详细内容，但是首先让我们来回答一个问题，“什么样才算是一个文件系统 ？” 一个文件系统应该涵盖以下所有点： - -1. **数据存储:** 对于任何一个文件系统来说，一个最主要的功能就是能够被当作一个容器结构来存储和恢复数据。 - -2. **命名空间:** 命名空间是一个提供了命名规则和数据结构的用于命名与组织的方法学。 - -3. **安全模型:** 一个用于定义访问权限的策略。 - -4. **API:** 指的是调用了操作这个系统的对象的系统方法，这些对象诸如目录和文件。 - -5. **实现:** 能够实现以上几点的软件。 - -本文内容的讨论主要集中于上述几点中的第一项并探索为一个 EXT 文件系统的数据存储提供逻辑框架的元数据结构。 - -### EXT 文件系统历史 - -虽然 EXT 文件系统是为 Linux 编写的，但其真正起源于 Minix 操作系统和 Minix 文件系统，而 Minix 最早发布于 1987，早于 Linux 5 年。如果我们从 EXT 文件系统大家族的 Minix 起源来观察其历史与技术发展那么理解 EXT4 文件系统就会简单得多。 - -### Minix - -当 Linux Torvalds 在写最初的 Linux 内核的时候，他需要一个文件系统但是他又不想自己写一个。于是他简单地把 [Minix 文件系统][14] 加了进去，这个 Minix 文件系统是由 [Andrew S. Tanenbaum][15] 写的同时也是 Tanenbaum 的 Minix 操作系统的一部分。[Minix][16] 是一个类 Unix 风格的操作系统，最初编写它的原因是用于教育。Minx 的代码是自由可用的且经过适当的许可的，所以 Torvalds 可以把它用 Linux 的最初版本里。 - -Minix 有以下这些结构，其中的大部分位于生成文件系统的分区中： - -* [**boot 扇区**][6] 是硬盘驱动安装后的第一个扇区。这个 boot 块包含了一个非常小的 boot 记录和一个分区表。 - -* 每一个分区的第一个块都是一个包含了元数据的 **superblock** ，这些元数据定义了其他文件系统的结构并将其定位于物理硬盘的具体分区上。 - -* 一个 **inode 位图块** 决定了哪些 inode 是在使用中的，哪一些是未使用的。 - -* **inode** 在硬盘上有它们自己的空间。每一个 inode 都包含了一个文件的信息包括其所处的数据块的位置，也就是该文件所处的区域。 - -* 一个 **区位图** 用于保持追踪数据区域的使用和未使用情况。 - -* 一个 **数据区**, 这里是数据存储的地方。 - -对上述了两种位图类型来说，一个 bit 表示一个制定的数据区或者一个指定的 inode. 如果这个 bit 是 0 则表示这个数据区或者这个 inode 是可以使用的，如果是 1 则表示正在使用中。 - -那么，[inode][17] 又是什么呢 ? 就是 index-node (索引节点)的简写。 inode 是位于磁盘上的一个 256 字节的块，用于存储和该 inode 对应的文件的相关数据。这些数据包含了文件的大小、文件的所有者和所属组的用户的 ID、文件模式（即访问权限）以及三个时间戳用于指定：该文件最后的访问时间、该文件的最后修改时间和该 inode 中的数据的最后修改时间。 - -同时，这个 inode 还包含了指向了其所对应的文件的数据在硬盘中的位置。在 Minix 和 EXT1-3 文件系统中，inode 表示的是一系列的的数据区和块。Minix 文件系统的 inode 支持 9 个数据块包括 7 个直接数据块和 2 个间接数据块。如果你想要更深入的了解，这里有一个优秀的 PDF 详细地描述了 [Minix 文件系统街头][18] 。同时你也可以在维基百科上对 [inode 指针结构][19] 做一个快速的浏览。 - -### EXT - -原生的 [EXT 文件系统][20] (指经过扩展的) 是由 [Rémy Card][21] 编写并于 1992 年与 Linux 一同发行。主要是为了克服 Minix 文件系统中的一些文件大小限制的问题。其中，最主要的结构变化就是文件系统中的元数据。它基于 Unix 文件系统 （UFS），也被称为伯克利快速文件系统（FFS）。我发现只有很少一部分关于 EXT 文件系统的发行信息是可以被验证的，显然这是因为其存在着严重的问题并且它很快地被 EXT2 文件系统取代了。 - -### EXT2 - -[EXT2 文件系统][22] 就相当地成功，它在 Linux 发行版中存活了多年。它是我在 1997 年开始使用 Red Hat Linux 时认识的第一个文件系统。实际上，EXT2 文件系统有着和 EXT 文件系统基本相同的元数据结构。然而 EXT2 更高瞻远瞩，因为其元数据结构之间留有很多磁盘空间供将来使用。 - -和 Minix 类似，EXT2 也有一个[boot 扇区][23] ，它是硬盘驱动安装后的第一个扇区。它包含了少量的 boot 记录和一个分区表。接着 boot 扇区之后是一些保留的空间，它跨越引导记录和通常位于下一个柱面的硬盘驱动器上的第一个分区之间的空间。 [GRUB2] [24] - 也可能是GRUB1 - 将此空间用于其部分启动代码。 - -每个 EXT2 分区中的空间分为各柱面组，它允许更精细地管理数据空间。 根据我的经验，每一组大小通常约为8MB。 下面的图1显示了一个柱面组的基本结构。 柱面中的数据分配单元是块，通常大小为4K。 - -![cylindergroup-01_1.png](https://opensource.com/sites/default/files/images/life-uploads/cylindergroup-01_1.png) - -Figure 1: EXT 文件系统中的柱面组的结构 - -柱面组中的第一个块是一个超级块，它包含了一个定义了其他文件系统的结构并将其定位于物理硬盘的具体分区上的元数据。分区中有一些柱面组还会有备用超级块，但并不是所有的柱面组都有。我们还可以使用例如 **dd** 等磁盘工具来拷贝备用超级块的内容到主超级块上以达到更换损坏超级块的目的。虽然这种情况不会经常发生，但是在几年前我的一个超级块损坏了，我就是用这种方法来修复的。幸好，我很有先见之明地使用了 **dumpe2fs** 命令来备份了我的分区描述符信息到我的系统上。 - -以下是 **dumpe2fs** 命令的一部分输出。这部分输出主要是超级块上包含的一些元数据，同时也是文件系统上的前两个柱面组的数据。 - -``` -# dumpe2fs /dev/sda1 -Filesystem volume name: boot -Last mounted on: /boot -Filesystem UUID: 79fc5ed8-5bbc-4dfe-8359-b7b36be6eed3 -Filesystem magic number: 0xEF53 -Filesystem revision #: 1 (dynamic) -Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir nlink extra_isize -Filesystem flags: signed_directory_hash -Default mount options: user_xattr acl -Filesystem state: clean -Errors behavior: Continue -Filesystem OS type: Linux -Inode count: 122160 -Block count: 488192 -Reserved block count: 24409 -Free blocks: 376512 -Free inodes: 121690 -First block: 0 -Block size: 4096 -Fragment size: 4096 -Group descriptor size: 64 -Reserved GDT blocks: 238 -Blocks per group: 32768 -Fragments per group: 32768 -Inodes per group: 8144 -Inode blocks per group: 509 -Flex block group size: 16 -Filesystem created: Tue Feb 7 09:33:34 2017 -Last mount time: Sat Apr 29 21:42:01 2017 -Last write time: Sat Apr 29 21:42:01 2017 -Mount count: 25 -Maximum mount count: -1 -Last checked: Tue Feb 7 09:33:34 2017 -Check interval: 0 () -Lifetime writes: 594 MB -Reserved blocks uid: 0 (user root) -Reserved blocks gid: 0 (group root) -First inode: 11 -Inode size: 256 -Required extra isize: 32 -Desired extra isize: 32 -Journal inode: 8 -Default directory hash: half_md4 -Directory Hash Seed: c780bac9-d4bf-4f35-b695-0fe35e8d2d60 -Journal backup: inode blocks -Journal features: journal_64bit -Journal size: 32M -Journal length: 8192 -Journal sequence: 0x00000213 -Journal start: 0 - -Group 0: (Blocks 0-32767) - Primary superblock at 0, Group descriptors at 1-1 - Reserved GDT blocks at 2-239 - Block bitmap at 240 (+240) - Inode bitmap at 255 (+255) - Inode table at 270-778 (+270) - 24839 free blocks, 7676 free inodes, 16 directories - Free blocks: 7929-32767 - Free inodes: 440, 470-8144 -Group 1: (Blocks 32768-65535) - Backup superblock at 32768, Group descriptors at 32769-32769 - Reserved GDT blocks at 32770-33007 - Block bitmap at 241 (bg #0 + 241) - Inode bitmap at 256 (bg #0 + 256) - Inode table at 779-1287 (bg #0 + 779) - 8668 free blocks, 8142 free inodes, 2 directories - Free blocks: 33008-33283, 33332-33791, 33974-33975, 34023-34092, 34094-34104, 34526-34687, 34706-34723, 34817-35374, 35421-35844, 35935-36355, 36357-36863, 38912-39935, 39940-40570, 42620-42623, 42655, 42674-42687, 42721-42751, 42798-42815, 42847, 42875-42879, 42918-42943, 42975, 43000-43007, 43519, 43559-44031, 44042-44543, 44545-45055, 45116-45567, 45601-45631, 45658-45663, 45689-45695, 45736-45759, 45802-45823, 45857-45887, 45919, 45950-45951, 45972-45983, 46014-46015, 46057-46079, 46112-46591, 46921-47103, 49152-49395, 50027-50355, 52237-52255, 52285-52287, 52323-52351, 52383, 52450-52479, 52518-52543, 52584-52607, 52652-52671, 52734-52735, 52743-53247 - Free inodes: 8147-16288 -Group 2: (Blocks 65536-98303) - Block bitmap at 242 (bg #0 + 242) - Inode bitmap at 257 (bg #0 + 257) - Inode table at 1288-1796 (bg #0 + 1288) - 6326 free blocks, 8144 free inodes, 0 directories - Free blocks: 67042-67583, 72201-72994, 80185-80349, 81191-81919, 90112-94207 - Free inodes: 16289-24432 -Group 3: (Blocks 98304-131071) - - -``` - -每一个柱面组都有自己的 inode 位图用于判定该柱面组中的哪些 inode 是使用中的而哪些又是未被使用的。每一个柱面组的 inode 都有它们自己的空间。每一个 inode 都包含了对应的文件的相关信息，包括其位于该文件的数据块中的位置。这个块位图纪录了文件系统中的使用中和非使用中的数据块。请注意，在上面的输出中有大量关于文件系统的数据。在非常大的文件系统上，组数据可以运行到数百页的长度。 组元数据包括组中所有空闲数据块的列表。 - -EXT 文件系统实现了数据分配策略以确保产生最少的文件碎片。减少文件碎片可以提高文件系统的性能。这些策略会在下面的 EXT4 中描述到。 - -我所遇见的关于 EXT2 文件系统最大的问题是 **fsck** (文件系统检查) 程序这一环节占用了很长一段时间来定位和校准文件系统中的所有不一致性导致其共花费了数个小时来修复一个崩溃。有一次我的其中一台电脑共花费了 28 个小时在一次崩溃后重新启动时恢复磁盘上，并且是在磁盘被检测量在几百兆字节大小的情况下。 - -### EXT3 - -[EXT3 文件系统][25] 具有克服 **fsck** 程序需要完全恢复在文件更新操作期间发生的不正确关机损坏的磁盘结构所需的大量时间的单一目标。EXT 文件系统的唯一新增是 [日志][26]，它将提前记录将对文件系统执行的更改。 磁盘结构的其余部分与 EXT2 中的相同。 - -作为一个先前的版本，除了直接写入数据到磁盘的数据区域外，EXT3 的日志在写入元数据时同时会也写入文件数据到磁盘上的一个指定数据区域。一旦这些数据安全地到达硬盘，它就可以几乎零丢失率地被合并或者被追加到目标文件。当这些数据被提交到磁盘上的数据区域上，这些日志就会随即更新，这样在系统发生故障之前，文件系统将保持一致状态，才能提交日志中的所有数据。在下次启动时，将检查文件系统的不一致性，然后将日志中保留的数据提交到磁盘的数据区，以完成对目标文件的更新。 - -日记功能确实降低了数据写入性能，但是有三个可用于日志的选项，允许用户在性能和数据完整性和安全性之间进行选择。 我的个人更偏向于选择安全性，因为我的环境不需要大量的磁盘写入活动。 - -日志功能减少了在从几小时（甚至几天）到几分钟之间的失败后检查硬盘驱动器所需的时间。 多年来，我遇到了很多问题导致了我的系统崩溃。 要详细说的话恐怕还得再写一篇文章，但这足以说明大多数是我自己造成的，就比如不小心踢掉一个电源插头。 幸运的是，EXT日志文件系统将启动恢复时间缩短到两三分钟。 此外，自从我开始使用带日志记录的EXT3，我从来没有遇到丢失数据的问题。 - -EXT3 的日志功能可以关闭，然后作为 EXT2 文件系统。 该日志本身仍然是存在的，只是状态为空且未使用。 只需使用类型参数使用 mount 命令来 remount 到分区即可指定EXT2 \。 你可以从命令行执行此操作，但是具体还是取决于你正在使用的文件系统，但你可以更改 **/ etc / fstab** 文件中的类型说明符，然后重新启动。 我强烈建议不要将 EXT3文件系统安装为 EXT2 ，因为这会具有丢失数据和增加恢复时间的潜在可能性。 - -EXT2 文件系统可以使用如下命令来通过日志升级到 EXT3 。 - -``` -tune2fs -j /dev/sda1 -``` - - **/dev/sda1** 表示驱动和分区的标识符。同时要注意修改 **/etc/fstab** 中的文件类型标识符并 remount 分区或者重启系统以确保修改生效。 - -### EXT4 - -[EXT4 filesystem][27]主要提高了性能、可靠性和容量。位了提高可靠性，它新增了元数据和日志校验和。同时位了满足各种关键任务要求，文件系统新增了纳秒级别的时间戳。在时间戳字段中添加两个高位来延迟时间戳的 [2038 年的问题][28] ，在 EXT4 文件系统至少可达到 2446 年。 - -在 EXT4 中，数据分配从固定块更改为盘区，盘区由硬盘驱动器上的开始和结束位置来描述。这使得可以在单个 inode 指针条目中描述非常长的物理连续的文件，这可以显着减少描述大文件中所有数据的位置所需的指针数。 EXT4 中已经实施了其他分配策略，以进一步减少碎片化。 - -EXT4 通过将新创建的文件分散在磁盘上，从而使其不会全部聚集在磁盘起始位置，就像早期的PC文件系统一样，减少了碎片。文件分配算法尝试在柱面组中尽可能均匀地扩展文件，并且当需要分段时，要使不连续文件扩展区尽可能靠近同一文件中的其他文件，以尽可能减少头部搜索和旋转等待时间尽可能的当创建新文件或扩展现有文件时，使用其他策略来预分配额外的磁盘空间。这有助于确保扩展文件不会自动导致其分段。新文件不会在现有文件之后立即分配，这也可以防止现有文件的碎片化。 - -除了磁盘上数据的实际位置外，EXT4 使用诸如延迟分配的功能策略，以允许文件系统在分配空间之前收集正在写入磁盘的所有数据。这可以提高数据空间将是连续的可能性。 - -较旧的EXT文件系统（如 EXT2 和 EXT3）可以作为 EXT4 进行 mount ，以使其性能获得较小的提升。不幸的是，这需要关闭 EXT4 的一些重要的新功能，所以我建议不要这样做。 - -自 Fedora 14 以来，EXT4 一直是 Fedora 的默认文件系统。我们可以使用 Fedora 文档中描述的 [procedure ][29] 将EXT3文件系统升级到EXT4，但是由于之前仍然存留d的 EXT3 元数据结构，它的性能仍将受到影响。从 EXT3 升级到 EXT4 的最佳方法是备份目标文件系统分区上的所有数据，使用 **mkfs** 命令将空EXT4文件系统写入分区，然后从备份中恢复所有数据。 - -### Inode - -以前描述的 inode 是EXT文件系统中的元数据的关键组件。 图 2 显示了 inode 和存储在硬盘驱动器上的数据之间的关系。 该图是单个文件的目录和 inode，在这种情况下，可能会产生高度碎片。 EXT 文件系统可以积极地减少碎片，所以不太可能会看到有这么多间接数据块或扩展盘的文件。 实际上，如下所示，EXT文件系统中的碎片非常低，所以大多数 inode 只使用一个或两个直接数据指针，也不使用间接指针。 - -![inodesanddataallocation-01_0.png](https://opensource.com/sites/default/files/images/life-uploads/inodesanddataallocation-01_0.png) - -图 2 ：inode 存储有关每个文件的信息，并使 EXT 文件系统能够查找属于它的所有数据。 - -inode 不包含文件的名称。通过目录条目访问文件，目录条目本身是文件的名称，并包含指向 inode 的指针。该指针的值是 inode 号。文件系统中的每个 inode 都具有唯一的 ID 号，但同一台计算机上的其他文件系统（甚至相同的硬盘驱动器）中的 inode 可以具有相同的 inode 号。这对[links][30] 存在影响，但是这个讨论超出了本文的范围。 - -inod e包含有关该文件的元数据，包括其类型和权限以及其大小。 inode 还包含 15 个指针的空格，用于描述柱面组数据部分中数据块或扩展区的位置和长度。十二个指针提供对数据扩展区的直接访问，并且应该足以处理大多数文件。然而，对于具有重大分段的文件，有必要以间接节点的形式具有一些附加功能。从技术上讲，这些不是真正的节点，所以我在这里使用这个术语“节点”来方便。 - -间接节点是文件系统中的正常数据块，它仅用于描述数据而不用于存储元数据，因此可以支持超过 15 个条目。例如，4K 的块大小可以支持 512 个 4 字节间接节点，允许单个文件的 **12（直接）+ 512（间接）= 524** 范围。还支持双重和三重间接节点支持，但我们大多数人不太可能遇到需要许多扩展的文件。 - -### 数据碎片 - -对于许多较旧的 PC 文件系统，如 FAT（及其所有变体）和 NTFS，碎片一直是导致磁盘性能下降的重大问题。 碎片整理对于其本身和一些专门的整理软件来说已经称为了一项专门的工程，其效果范围从非常有效到仅仅是微乎其微。 - -Linux 的扩展文件系统使用数据分配策略，有助于最小化硬盘驱动器上的文件碎片，并在发生碎片时减少碎片的影响。 你可以使用 EXT 文件系统上的 **fsck** 命令检查文件系统的整体碎片。 以下示例检查主工作站的主目录，只有 1.5％ 的碎片。 确保使用 **- n** 参数，因为它会阻止 **fsck** 对扫描文件系统采取的任何操作。 - -``` -fsck -fn /dev/mapper/vg_01-home -``` - -我曾经进行过一些理论计算，以确定磁盘碎片整理是否会导致任何明显的性能提升。 虽然我做了一些假设，我使用的磁盘性能数据来自一个新的 300GB 的西部数字硬盘驱动器，具有 2.0ms 的追踪到追踪时间。 此示例中的文件数是在计算当天文件系统中存在的实际数。 我假设有相当大量的碎片文件（约 20％）每天都会被触动。 - -| **Total files** | **271,794** | -|--|--| -| % fragmentation | 5.00% | -| Discontinuities | 13,590 | -|   |   | -| % fragmented files touched per day | 20% (assume) | -| Number of additional seeks | 2,718 | -| Average seek time | 10.90 ms | -| Total additional seek time per day | 29.63 sec | -|   | 0.49 min | -|   |   | -| Track-to-track seek time | 2.00 ms | -| Total additional seek time per day | 5.44 sec | -|   | 0.091 min | - -表 1: 碎片对磁盘性能的理论影响 - -我对每天的全部追加寻道时间进行了两次计算，一次是单磁道寻道时间，这是由于EXT文件分配策略而导致大多数文件的可能性更大的情况，一个是平均搜索时间，我认为这将是一个公平的最坏情况。 - -从表 1 可以看出，对绝大多数应用程序而言，碎片化对具有甚至适度性能的硬盘驱动器的现代EXT文件系统的影响将是微乎其微的。您可以将您的环境中的数字插入到您自己的类似电子表格中，以了解你对性能影响的期望。这种类型的计算不一定能够代表实际的性能，但它可以提供一些洞察碎片化及其对系统的理论影响。 - -我的大部分分区的碎片率都在 1.5％ 左右或 1.6％，我有一个分区有 3.3％ 的碎片，但是这是一个大的 128GB 文件系统，具有少于100 个非常大的 ISO 映像文件; 多年来，我不得不扩张分区，因为它已经太满了。 - -这并不是说一些应用的环境不需要更多的保证，甚至更少的碎片。 EXT 文件系统可以由有经验和知识的管理员小心调整，管理员可以调整参数以抵消特定的工作负载类型。这个工作可以在文件系统创建的时候或稍后使用 **tune2fs** 命令时完成。每一次调整变化的结果应进行测试，精心的记录和分析，以确保目标环境的最佳性能。在最坏的情况下，如果性能不能提高到期望的水平，则其他文件系统类型可能更适合特定的工作负载。并记住，在单个主机系统上使用混合文件系统类型以匹配放在每个文件系统上的负载是常见的。 - -由于大多数 EXT 文件系统的碎片数量较少，因此无需进行碎片整理。在任何情况下，EXT 文件系统都没有安全的碎片整理工具。有几个工具允许你检查单个文件的碎片或文件系统中剩余可用空间的碎片。有一个工具，**e4defrag**，它将对剩余可用空间允许的文件，目录或文件系统进行碎片整理。顾名思义，它只适用于 EXT4 文件系统中的文件，并且它还有一其它的些限制。 - -如果有必要在 EXT 文件系统上执行完整的碎片整理，则只有一种方法能够可靠地工作。你必须将文件系统中的所有要进行碎片整理的文件在确保在安全复制到其他位置后将其删除。如果可能，你可以增加文件系统的大小，以帮助减少将来的碎片。然后将文件复制回目标文件系统。但是其实即使这样也不能保证所有文件都被完全碎片整理。 - -### 总结 - -EXT 文件系统在一些 Linux 发行版本上作为默认文件系统已经超过二十多年了。它们用最少的维护代价提供了稳定性、高可用性、可靠性和其他各种表现。我尝试过一些其它的文件系统但最终都还是回归到 EXT。每一个我在工作中使用到 Linux 的地方都使用到了 EXT 文件系统，同时发现了它们适用于任何主流的负载。毫无疑问，EXT4 文件系统应该被用于大部分的 Linux 文件系统上，除非我们有明显的使用其它文件系统的理由。 - --------------------------------------------------------------------------------- - -作者简介： - -David Both - David Both 是一名 Linux 于开源的贡献者，目前居住在北卡罗莱纳州的罗利。他从事 IT 行业有 40 余年并在 IBM 中从事 OS/2 培训约 20 余年。在 IBM 就职期间，他在 1981 年为最早的 IBM PC 写了一个培训课程。他已经为红帽教授了 RHCE 课程，曾在 MCI Worldcom，思科和北卡罗来纳州工作。 他使用 Linux 和开源软件工作了近 20 年。 - -------------------- - -via: https://opensource.com/article/17/5/introduction-ext4-filesystem - -作者：[David Both ][a] -译者：[chenxinlong](https://github.com/chenxinlong) -校对：[校对者ID](https://github.com/校对者ID) - -本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 - -[a]:https://opensource.com/users/dboth -[1]:https://opensource.com/resources/what-is-linux?src=linux_resource_menu -[2]:https://opensource.com/resources/what-are-linux-containers?src=linux_resource_menu -[3]:https://developers.redhat.com/promotions/linux-cheatsheet/?intcmp=7016000000127cYAAQ -[4]:https://developers.redhat.com/cheat-sheet/advanced-linux-commands-cheatsheet?src=linux_resource_menu&intcmp=7016000000127cYAAQ -[5]:https://opensource.com/tags/linux?src=linux_resource_menu -[6]:https://en.wikipedia.org/wiki/Boot_sector -[7]:https://opensource.com/article/17/5/introduction-ext4-filesystem?rate=B4QU3W_JYmEKsIKZf5yqMpztt7CRF6uzC0wfNBidEbs -[8]:https://www.flickr.com/photos/wwarby/11644168395 -[9]:https://www.flickr.com/photos/wwarby/11644168395 -[10]:https://opensource.com/users/jason-baker -[11]:https://creativecommons.org/licenses/by/2.0/ -[12]:https://opensource.com/life/16/10/introduction-linux-filesystems -[13]:https://opensource.com/life/15/9/everything-is-a-file -[14]:https://en.wikipedia.org/wiki/MINIX_file_system -[15]:https://en.wikipedia.org/wiki/Andrew_S._Tanenbaum -[16]:https://en.wikipedia.org/wiki/MINIX -[17]:https://en.wikipedia.org/wiki/Inode -[18]:http://ohm.hgesser.de/sp-ss2012/Intro-MinixFS.pdf -[19]:https://en.wikipedia.org/wiki/Inode_pointer_structure -[20]:https://en.wikipedia.org/wiki/Extended_file_system -[21]:https://en.wikipedia.org/wiki/R%C3%A9my_Card -[22]:https://en.wikipedia.org/wiki/Ext2 -[23]:https://en.wikipedia.org/wiki/Boot_sector -[24]:https://opensource.com/article/17/2/linux-boot-and-startup -[25]:https://en.wikipedia.org/wiki/Ext3 -[26]:https://en.wikipedia.org/wiki/Journaling_file_system -[27]:https://en.wikipedia.org/wiki/Ext4 -[28]:https://en.wikipedia.org/wiki/Year_2038_problem -[29]:https://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Guide/ext4converting.html -[30]:https://en.wikipedia.org/wiki/Hard_link -[31]:https://opensource.com/user/14106/feed -[32]:https://opensource.com/article/17/5/introduction-ext4-filesystem#comments -[33]:https://opensource.com/users/dboth From 1c788ae11f1d11efbffe320e22a783b8c4a23bde Mon Sep 17 00:00:00 2001 From: chenxinlong <237448382@qq.com> Date: Sat, 24 Jun 2017 23:22:33 +0800 Subject: [PATCH 14/17] mv to translated --- ...introduction to Linux s EXT4 filesystem.md | 301 ++++++++++++++++++ 1 file changed, 301 insertions(+) create mode 100644 translated/tech/20170525 An introduction to Linux s EXT4 filesystem.md diff --git a/translated/tech/20170525 An introduction to Linux s EXT4 filesystem.md b/translated/tech/20170525 An introduction to Linux s EXT4 filesystem.md new file mode 100644 index 0000000000..3bbd63ff73 --- /dev/null +++ b/translated/tech/20170525 An introduction to Linux s EXT4 filesystem.md @@ -0,0 +1,301 @@ +Linux 的 EXT4 文件系统简介 +============================================================ + +### 让我们大概地从 EXT4 的历史、特性以及最佳实践这几个方面来学习它和之前的所有的 EXT 文件系统有何不同。 + +![An introduction to the EXT4 filesystem](https://opensource.com/sites/default/files/styles/image-full-size/public/images/life/hard_drives.png?itok=yZWyaSO6 "An introduction to the EXT4 filesystem") +>图片来自 : [WIlliam][8][ Warby][9]. 由 [Jason Baker][10] 编辑. Creative Commons [BY-SA 2.0][11]. + +在之前关于 Linux 文件系统的文章里，我写过一篇 [an introduction to Linux filesystems][12] 和一些更高级的概念例如 [everything is a file][13]. 我想要更深入地了解 EXT 文件系统的特性的详细内容，但是首先让我们来回答一个问题，“什么样才算是一个文件系统 ？” 一个文件系统应该涵盖以下所有点： + +1. **数据存储:** 对于任何一个文件系统来说，一个最主要的功能就是能够被当作一个容器结构来存储和恢复数据。 + +2. **命名空间:** 命名空间是一个提供了命名规则和数据结构的用于命名与组织的方法学。 + +3. **安全模型:** 一个用于定义访问权限的策略。 + +4. **API:** 指的是调用了操作这个系统的对象的系统方法，这些对象诸如目录和文件。 + +5. **实现:** 能够实现以上几点的软件。 + +本文内容的讨论主要集中于上述几点中的第一项并探索为一个 EXT 文件系统的数据存储提供逻辑框架的元数据结构。 + +### EXT 文件系统历史 + +虽然 EXT 文件系统是为 Linux 编写的，但其真正起源于 Minix 操作系统和 Minix 文件系统，而 Minix 最早发布于 1987，早于 Linux 5 年。如果我们从 EXT 文件系统大家族的 Minix 起源来观察其历史与技术发展那么理解 EXT4 文件系统就会简单得多。 + +### Minix + +当 Linux Torvalds 在写最初的 Linux 内核的时候，他需要一个文件系统但是他又不想自己写一个。于是他简单地把 [Minix 文件系统][14] 加了进去，这个 Minix 文件系统是由 [Andrew S. Tanenbaum][15] 写的同时也是 Tanenbaum 的 Minix 操作系统的一部分。[Minix][16] 是一个类 Unix 风格的操作系统，最初编写它的原因是用于教育。Minx 的代码是自由可用的且经过适当的许可的，所以 Torvalds 可以把它用 Linux 的最初版本里。 + +Minix 有以下这些结构，其中的大部分位于生成文件系统的分区中： + +* [**boot 扇区**][6] 是硬盘驱动安装后的第一个扇区。这个 boot 块包含了一个非常小的 boot 记录和一个分区表。 + +* 每一个分区的第一个块都是一个包含了元数据的 **superblock** ，这些元数据定义了其他文件系统的结构并将其定位于物理硬盘的具体分区上。 + +* 一个 **inode 位图块** 决定了哪些 inode 是在使用中的，哪一些是未使用的。 + +* **inode** 在硬盘上有它们自己的空间。每一个 inode 都包含了一个文件的信息包括其所处的数据块的位置，也就是该文件所处的区域。 + +* 一个 **区位图** 用于保持追踪数据区域的使用和未使用情况。 + +* 一个 **数据区**, 这里是数据存储的地方。 + +对上述了两种位图类型来说，一个 bit 表示一个制定的数据区或者一个指定的 inode. 如果这个 bit 是 0 则表示这个数据区或者这个 inode 是可以使用的，如果是 1 则表示正在使用中。 + +那么，[inode][17] 又是什么呢 ? 就是 index-node (索引节点)的简写。 inode 是位于磁盘上的一个 256 字节的块，用于存储和该 inode 对应的文件的相关数据。这些数据包含了文件的大小、文件的所有者和所属组的用户的 ID、文件模式（即访问权限）以及三个时间戳用于指定：该文件最后的访问时间、该文件的最后修改时间和该 inode 中的数据的最后修改时间。 + +同时，这个 inode 还包含了指向了其所对应的文件的数据在硬盘中的位置。在 Minix 和 EXT1-3 文件系统中，inode 表示的是一系列的的数据区和块。Minix 文件系统的 inode 支持 9 个数据块包括 7 个直接数据块和 2 个间接数据块。如果你想要更深入的了解，这里有一个优秀的 PDF 详细地描述了 [Minix 文件系统街头][18] 。同时你也可以在维基百科上对 [inode 指针结构][19] 做一个快速的浏览。 + +### EXT + +原生的 [EXT 文件系统][20] (指经过扩展的) 是由 [Rémy Card][21] 编写并于 1992 年与 Linux 一同发行。主要是为了克服 Minix 文件系统中的一些文件大小限制的问题。其中，最主要的结构变化就是文件系统中的元数据。它基于 Unix 文件系统 （UFS），也被称为伯克利快速文件系统（FFS）。我发现只有很少一部分关于 EXT 文件系统的发行信息是可以被验证的，显然这是因为其存在着严重的问题并且它很快地被 EXT2 文件系统取代了。 + +### EXT2 + +[EXT2 文件系统][22] 就相当地成功，它在 Linux 发行版中存活了多年。它是我在 1997 年开始使用 Red Hat Linux 时认识的第一个文件系统。实际上，EXT2 文件系统有着和 EXT 文件系统基本相同的元数据结构。然而 EXT2 更高瞻远瞩，因为其元数据结构之间留有很多磁盘空间供将来使用。 + +和 Minix 类似，EXT2 也有一个[boot 扇区][23] ，它是硬盘驱动安装后的第一个扇区。它包含了少量的 boot 记录和一个分区表。接着 boot 扇区之后是一些保留的空间，它跨越引导记录和通常位于下一个柱面的硬盘驱动器上的第一个分区之间的空间。 [GRUB2] [24] - 也可能是GRUB1 - 将此空间用于其部分启动代码。 + +每个 EXT2 分区中的空间分为各柱面组，它允许更精细地管理数据空间。 根据我的经验，每一组大小通常约为8MB。 下面的图1显示了一个柱面组的基本结构。 柱面中的数据分配单元是块，通常大小为4K。 + +![cylindergroup-01_1.png](https://opensource.com/sites/default/files/images/life-uploads/cylindergroup-01_1.png) + +Figure 1: EXT 文件系统中的柱面组的结构 + +柱面组中的第一个块是一个超级块，它包含了一个定义了其他文件系统的结构并将其定位于物理硬盘的具体分区上的元数据。分区中有一些柱面组还会有备用超级块，但并不是所有的柱面组都有。我们还可以使用例如 **dd** 等磁盘工具来拷贝备用超级块的内容到主超级块上以达到更换损坏超级块的目的。虽然这种情况不会经常发生，但是在几年前我的一个超级块损坏了，我就是用这种方法来修复的。幸好，我很有先见之明地使用了 **dumpe2fs** 命令来备份了我的分区描述符信息到我的系统上。 + +以下是 **dumpe2fs** 命令的一部分输出。这部分输出主要是超级块上包含的一些元数据，同时也是文件系统上的前两个柱面组的数据。 + +``` +# dumpe2fs /dev/sda1 +Filesystem volume name: boot +Last mounted on: /boot +Filesystem UUID: 79fc5ed8-5bbc-4dfe-8359-b7b36be6eed3 +Filesystem magic number: 0xEF53 +Filesystem revision #: 1 (dynamic) +Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file dir nlink extra_isize +Filesystem flags: signed_directory_hash +Default mount options: user_xattr acl +Filesystem state: clean +Errors behavior: Continue +Filesystem OS type: Linux +Inode count: 122160 +Block count: 488192 +Reserved block count: 24409 +Free blocks: 376512 +Free inodes: 121690 +First block: 0 +Block size: 4096 +Fragment size: 4096 +Group descriptor size: 64 +Reserved GDT blocks: 238 +Blocks per group: 32768 +Fragments per group: 32768 +Inodes per group: 8144 +Inode blocks per group: 509 +Flex block group size: 16 +Filesystem created: Tue Feb 7 09:33:34 2017 +Last mount time: Sat Apr 29 21:42:01 2017 +Last write time: Sat Apr 29 21:42:01 2017 +Mount count: 25 +Maximum mount count: -1 +Last checked: Tue Feb 7 09:33:34 2017 +Check interval: 0 () +Lifetime writes: 594 MB +Reserved blocks uid: 0 (user root) +Reserved blocks gid: 0 (group root) +First inode: 11 +Inode size: 256 +Required extra isize: 32 +Desired extra isize: 32 +Journal inode: 8 +Default directory hash: half_md4 +Directory Hash Seed: c780bac9-d4bf-4f35-b695-0fe35e8d2d60 +Journal backup: inode blocks +Journal features: journal_64bit +Journal size: 32M +Journal length: 8192 +Journal sequence: 0x00000213 +Journal start: 0 + +Group 0: (Blocks 0-32767) + Primary superblock at 0, Group descriptors at 1-1 + Reserved GDT blocks at 2-239 + Block bitmap at 240 (+240) + Inode bitmap at 255 (+255) + Inode table at 270-778 (+270) + 24839 free blocks, 7676 free inodes, 16 directories + Free blocks: 7929-32767 + Free inodes: 440, 470-8144 +Group 1: (Blocks 32768-65535) + Backup superblock at 32768, Group descriptors at 32769-32769 + Reserved GDT blocks at 32770-33007 + Block bitmap at 241 (bg #0 + 241) + Inode bitmap at 256 (bg #0 + 256) + Inode table at 779-1287 (bg #0 + 779) + 8668 free blocks, 8142 free inodes, 2 directories + Free blocks: 33008-33283, 33332-33791, 33974-33975, 34023-34092, 34094-34104, 34526-34687, 34706-34723, 34817-35374, 35421-35844, 35935-36355, 36357-36863, 38912-39935, 39940-40570, 42620-42623, 42655, 42674-42687, 42721-42751, 42798-42815, 42847, 42875-42879, 42918-42943, 42975, 43000-43007, 43519, 43559-44031, 44042-44543, 44545-45055, 45116-45567, 45601-45631, 45658-45663, 45689-45695, 45736-45759, 45802-45823, 45857-45887, 45919, 45950-45951, 45972-45983, 46014-46015, 46057-46079, 46112-46591, 46921-47103, 49152-49395, 50027-50355, 52237-52255, 52285-52287, 52323-52351, 52383, 52450-52479, 52518-52543, 52584-52607, 52652-52671, 52734-52735, 52743-53247 + Free inodes: 8147-16288 +Group 2: (Blocks 65536-98303) + Block bitmap at 242 (bg #0 + 242) + Inode bitmap at 257 (bg #0 + 257) + Inode table at 1288-1796 (bg #0 + 1288) + 6326 free blocks, 8144 free inodes, 0 directories + Free blocks: 67042-67583, 72201-72994, 80185-80349, 81191-81919, 90112-94207 + Free inodes: 16289-24432 +Group 3: (Blocks 98304-131071) + + +``` + +每一个柱面组都有自己的 inode 位图用于判定该柱面组中的哪些 inode 是使用中的而哪些又是未被使用的。每一个柱面组的 inode 都有它们自己的空间。每一个 inode 都包含了对应的文件的相关信息，包括其位于该文件的数据块中的位置。这个块位图纪录了文件系统中的使用中和非使用中的数据块。请注意，在上面的输出中有大量关于文件系统的数据。在非常大的文件系统上，组数据可以运行到数百页的长度。 组元数据包括组中所有空闲数据块的列表。 + +EXT 文件系统实现了数据分配策略以确保产生最少的文件碎片。减少文件碎片可以提高文件系统的性能。这些策略会在下面的 EXT4 中描述到。 + +我所遇见的关于 EXT2 文件系统最大的问题是 **fsck** (文件系统检查) 程序这一环节占用了很长一段时间来定位和校准文件系统中的所有不一致性导致其共花费了数个小时来修复一个崩溃。有一次我的其中一台电脑共花费了 28 个小时在一次崩溃后重新启动时恢复磁盘上，并且是在磁盘被检测量在几百兆字节大小的情况下。 + +### EXT3 + +[EXT3 文件系统][25] 具有克服 **fsck** 程序需要完全恢复在文件更新操作期间发生的不正确关机损坏的磁盘结构所需的大量时间的单一目标。EXT 文件系统的唯一新增是 [日志][26]，它将提前记录将对文件系统执行的更改。 磁盘结构的其余部分与 EXT2 中的相同。 + +作为一个先前的版本，除了直接写入数据到磁盘的数据区域外，EXT3 的日志在写入元数据时同时会也写入文件数据到磁盘上的一个指定数据区域。一旦这些数据安全地到达硬盘，它就可以几乎零丢失率地被合并或者被追加到目标文件。当这些数据被提交到磁盘上的数据区域上，这些日志就会随即更新，这样在系统发生故障之前，文件系统将保持一致状态，才能提交日志中的所有数据。在下次启动时，将检查文件系统的不一致性，然后将日志中保留的数据提交到磁盘的数据区，以完成对目标文件的更新。 + +日记功能确实降低了数据写入性能，但是有三个可用于日志的选项，允许用户在性能和数据完整性和安全性之间进行选择。 我的个人更偏向于选择安全性，因为我的环境不需要大量的磁盘写入活动。 + +日志功能减少了在从几小时（甚至几天）到几分钟之间的失败后检查硬盘驱动器所需的时间。 多年来，我遇到了很多问题导致了我的系统崩溃。 要详细说的话恐怕还得再写一篇文章，但这足以说明大多数是我自己造成的，就比如不小心踢掉一个电源插头。 幸运的是，EXT日志文件系统将启动恢复时间缩短到两三分钟。 此外，自从我开始使用带日志记录的EXT3，我从来没有遇到丢失数据的问题。 + +EXT3 的日志功能可以关闭，然后作为 EXT2 文件系统。 该日志本身仍然是存在的，只是状态为空且未使用。 只需使用类型参数使用 mount 命令来 remount 到分区即可指定EXT2 \。 你可以从命令行执行此操作，但是具体还是取决于你正在使用的文件系统，但你可以更改 **/ etc / fstab** 文件中的类型说明符，然后重新启动。 我强烈建议不要将 EXT3文件系统安装为 EXT2 ，因为这会具有丢失数据和增加恢复时间的潜在可能性。 + +EXT2 文件系统可以使用如下命令来通过日志升级到 EXT3 。 + +``` +tune2fs -j /dev/sda1 +``` + + **/dev/sda1** 表示驱动和分区的标识符。同时要注意修改 **/etc/fstab** 中的文件类型标识符并 remount 分区或者重启系统以确保修改生效。 + +### EXT4 + +[EXT4 filesystem][27]主要提高了性能、可靠性和容量。位了提高可靠性，它新增了元数据和日志校验和。同时位了满足各种关键任务要求，文件系统新增了纳秒级别的时间戳。在时间戳字段中添加两个高位来延迟时间戳的 [2038 年的问题][28] ，在 EXT4 文件系统至少可达到 2446 年。 + +在 EXT4 中，数据分配从固定块更改为盘区，盘区由硬盘驱动器上的开始和结束位置来描述。这使得可以在单个 inode 指针条目中描述非常长的物理连续的文件，这可以显着减少描述大文件中所有数据的位置所需的指针数。 EXT4 中已经实施了其他分配策略，以进一步减少碎片化。 + +EXT4 通过将新创建的文件分散在磁盘上，从而使其不会全部聚集在磁盘起始位置，就像早期的PC文件系统一样，减少了碎片。文件分配算法尝试在柱面组中尽可能均匀地扩展文件，并且当需要分段时，要使不连续文件扩展区尽可能靠近同一文件中的其他文件，以尽可能减少头部搜索和旋转等待时间尽可能的当创建新文件或扩展现有文件时，使用其他策略来预分配额外的磁盘空间。这有助于确保扩展文件不会自动导致其分段。新文件不会在现有文件之后立即分配，这也可以防止现有文件的碎片化。 + +除了磁盘上数据的实际位置外，EXT4 使用诸如延迟分配的功能策略，以允许文件系统在分配空间之前收集正在写入磁盘的所有数据。这可以提高数据空间将是连续的可能性。 + +较旧的EXT文件系统（如 EXT2 和 EXT3）可以作为 EXT4 进行 mount ，以使其性能获得较小的提升。不幸的是，这需要关闭 EXT4 的一些重要的新功能，所以我建议不要这样做。 + +自 Fedora 14 以来，EXT4 一直是 Fedora 的默认文件系统。我们可以使用 Fedora 文档中描述的 [procedure ][29] 将EXT3文件系统升级到EXT4，但是由于之前仍然存留d的 EXT3 元数据结构，它的性能仍将受到影响。从 EXT3 升级到 EXT4 的最佳方法是备份目标文件系统分区上的所有数据，使用 **mkfs** 命令将空EXT4文件系统写入分区，然后从备份中恢复所有数据。 + +### Inode + +以前描述的 inode 是EXT文件系统中的元数据的关键组件。 图 2 显示了 inode 和存储在硬盘驱动器上的数据之间的关系。 该图是单个文件的目录和 inode，在这种情况下，可能会产生高度碎片。 EXT 文件系统可以积极地减少碎片，所以不太可能会看到有这么多间接数据块或扩展盘的文件。 实际上，如下所示，EXT文件系统中的碎片非常低，所以大多数 inode 只使用一个或两个直接数据指针，也不使用间接指针。 + +![inodesanddataallocation-01_0.png](https://opensource.com/sites/default/files/images/life-uploads/inodesanddataallocation-01_0.png) + +图 2 ：inode 存储有关每个文件的信息，并使 EXT 文件系统能够查找属于它的所有数据。 + +inode 不包含文件的名称。通过目录条目访问文件，目录条目本身是文件的名称，并包含指向 inode 的指针。该指针的值是 inode 号。文件系统中的每个 inode 都具有唯一的 ID 号，但同一台计算机上的其他文件系统（甚至相同的硬盘驱动器）中的 inode 可以具有相同的 inode 号。这对[links][30] 存在影响，但是这个讨论超出了本文的范围。 + +inod e包含有关该文件的元数据，包括其类型和权限以及其大小。 inode 还包含 15 个指针的空格，用于描述柱面组数据部分中数据块或扩展区的位置和长度。十二个指针提供对数据扩展区的直接访问，并且应该足以处理大多数文件。然而，对于具有重大分段的文件，有必要以间接节点的形式具有一些附加功能。从技术上讲，这些不是真正的节点，所以我在这里使用这个术语“节点”来方便。 + +间接节点是文件系统中的正常数据块，它仅用于描述数据而不用于存储元数据，因此可以支持超过 15 个条目。例如，4K 的块大小可以支持 512 个 4 字节间接节点，允许单个文件的 **12（直接）+ 512（间接）= 524** 范围。还支持双重和三重间接节点支持，但我们大多数人不太可能遇到需要许多扩展的文件。 + +### 数据碎片 + +对于许多较旧的 PC 文件系统，如 FAT（及其所有变体）和 NTFS，碎片一直是导致磁盘性能下降的重大问题。 碎片整理对于其本身和一些专门的整理软件来说已经称为了一项专门的工程，其效果范围从非常有效到仅仅是微乎其微。 + +Linux 的扩展文件系统使用数据分配策略，有助于最小化硬盘驱动器上的文件碎片，并在发生碎片时减少碎片的影响。 你可以使用 EXT 文件系统上的 **fsck** 命令检查文件系统的整体碎片。 以下示例检查主工作站的主目录，只有 1.5％ 的碎片。 确保使用 **- n** 参数，因为它会阻止 **fsck** 对扫描文件系统采取的任何操作。 + +``` +fsck -fn /dev/mapper/vg_01-home +``` + +我曾经进行过一些理论计算，以确定磁盘碎片整理是否会导致任何明显的性能提升。 虽然我做了一些假设，我使用的磁盘性能数据来自一个新的 300GB 的西部数字硬盘驱动器，具有 2.0ms 的追踪到追踪时间。 此示例中的文件数是在计算当天文件系统中存在的实际数。 我假设有相当大量的碎片文件（约 20％）每天都会被触动。 + +| **Total files** | **271,794** | +|--|--| +| % fragmentation | 5.00% | +| Discontinuities | 13,590 | +|   |   | +| % fragmented files touched per day | 20% (assume) | +| Number of additional seeks | 2,718 | +| Average seek time | 10.90 ms | +| Total additional seek time per day | 29.63 sec | +|   | 0.49 min | +|   |   | +| Track-to-track seek time | 2.00 ms | +| Total additional seek time per day | 5.44 sec | +|   | 0.091 min | + +表 1: 碎片对磁盘性能的理论影响 + +我对每天的全部追加寻道时间进行了两次计算，一次是单磁道寻道时间，这是由于EXT文件分配策略而导致大多数文件的可能性更大的情况，一个是平均搜索时间，我认为这将是一个公平的最坏情况。 + +从表 1 可以看出，对绝大多数应用程序而言，碎片化对具有甚至适度性能的硬盘驱动器的现代EXT文件系统的影响将是微乎其微的。您可以将您的环境中的数字插入到您自己的类似电子表格中，以了解你对性能影响的期望。这种类型的计算不一定能够代表实际的性能，但它可以提供一些洞察碎片化及其对系统的理论影响。 + +我的大部分分区的碎片率都在 1.5％ 左右或 1.6％，我有一个分区有 3.3％ 的碎片，但是这是一个大的 128GB 文件系统，具有少于100 个非常大的 ISO 映像文件; 多年来，我不得不扩张分区，因为它已经太满了。 + +这并不是说一些应用的环境不需要更多的保证，甚至更少的碎片。 EXT 文件系统可以由有经验和知识的管理员小心调整，管理员可以调整参数以抵消特定的工作负载类型。这个工作可以在文件系统创建的时候或稍后使用 **tune2fs** 命令时完成。每一次调整变化的结果应进行测试，精心的记录和分析，以确保目标环境的最佳性能。在最坏的情况下，如果性能不能提高到期望的水平，则其他文件系统类型可能更适合特定的工作负载。并记住，在单个主机系统上使用混合文件系统类型以匹配放在每个文件系统上的负载是常见的。 + +由于大多数 EXT 文件系统的碎片数量较少，因此无需进行碎片整理。在任何情况下，EXT 文件系统都没有安全的碎片整理工具。有几个工具允许你检查单个文件的碎片或文件系统中剩余可用空间的碎片。有一个工具，**e4defrag**，它将对剩余可用空间允许的文件，目录或文件系统进行碎片整理。顾名思义，它只适用于 EXT4 文件系统中的文件，并且它还有一其它的些限制。 + +如果有必要在 EXT 文件系统上执行完整的碎片整理，则只有一种方法能够可靠地工作。你必须将文件系统中的所有要进行碎片整理的文件在确保在安全复制到其他位置后将其删除。如果可能，你可以增加文件系统的大小，以帮助减少将来的碎片。然后将文件复制回目标文件系统。但是其实即使这样也不能保证所有文件都被完全碎片整理。 + +### 总结 + +EXT 文件系统在一些 Linux 发行版本上作为默认文件系统已经超过二十多年了。它们用最少的维护代价提供了稳定性、高可用性、可靠性和其他各种表现。我尝试过一些其它的文件系统但最终都还是回归到 EXT。每一个我在工作中使用到 Linux 的地方都使用到了 EXT 文件系统，同时发现了它们适用于任何主流的负载。毫无疑问，EXT4 文件系统应该被用于大部分的 Linux 文件系统上，除非我们有明显的使用其它文件系统的理由。 + +-------------------------------------------------------------------------------- + +作者简介： + +David Both - David Both 是一名 Linux 于开源的贡献者，目前居住在北卡罗莱纳州的罗利。他从事 IT 行业有 40 余年并在 IBM 中从事 OS/2 培训约 20 余年。在 IBM 就职期间，他在 1981 年为最早的 IBM PC 写了一个培训课程。他已经为红帽教授了 RHCE 课程，曾在 MCI Worldcom，思科和北卡罗来纳州工作。 他使用 Linux 和开源软件工作了近 20 年。 + +------------------- + +via: https://opensource.com/article/17/5/introduction-ext4-filesystem + +作者：[David Both ][a] +译者：[chenxinlong](https://github.com/chenxinlong) +校对：[校对者ID](https://github.com/校对者ID) + +本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 + +[a]:https://opensource.com/users/dboth +[1]:https://opensource.com/resources/what-is-linux?src=linux_resource_menu +[2]:https://opensource.com/resources/what-are-linux-containers?src=linux_resource_menu +[3]:https://developers.redhat.com/promotions/linux-cheatsheet/?intcmp=7016000000127cYAAQ +[4]:https://developers.redhat.com/cheat-sheet/advanced-linux-commands-cheatsheet?src=linux_resource_menu&intcmp=7016000000127cYAAQ +[5]:https://opensource.com/tags/linux?src=linux_resource_menu +[6]:https://en.wikipedia.org/wiki/Boot_sector +[7]:https://opensource.com/article/17/5/introduction-ext4-filesystem?rate=B4QU3W_JYmEKsIKZf5yqMpztt7CRF6uzC0wfNBidEbs +[8]:https://www.flickr.com/photos/wwarby/11644168395 +[9]:https://www.flickr.com/photos/wwarby/11644168395 +[10]:https://opensource.com/users/jason-baker +[11]:https://creativecommons.org/licenses/by/2.0/ +[12]:https://opensource.com/life/16/10/introduction-linux-filesystems +[13]:https://opensource.com/life/15/9/everything-is-a-file +[14]:https://en.wikipedia.org/wiki/MINIX_file_system +[15]:https://en.wikipedia.org/wiki/Andrew_S._Tanenbaum +[16]:https://en.wikipedia.org/wiki/MINIX +[17]:https://en.wikipedia.org/wiki/Inode +[18]:http://ohm.hgesser.de/sp-ss2012/Intro-MinixFS.pdf +[19]:https://en.wikipedia.org/wiki/Inode_pointer_structure +[20]:https://en.wikipedia.org/wiki/Extended_file_system +[21]:https://en.wikipedia.org/wiki/R%C3%A9my_Card +[22]:https://en.wikipedia.org/wiki/Ext2 +[23]:https://en.wikipedia.org/wiki/Boot_sector +[24]:https://opensource.com/article/17/2/linux-boot-and-startup +[25]:https://en.wikipedia.org/wiki/Ext3 +[26]:https://en.wikipedia.org/wiki/Journaling_file_system +[27]:https://en.wikipedia.org/wiki/Ext4 +[28]:https://en.wikipedia.org/wiki/Year_2038_problem +[29]:https://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Guide/ext4converting.html +[30]:https://en.wikipedia.org/wiki/Hard_link +[31]:https://opensource.com/user/14106/feed +[32]:https://opensource.com/article/17/5/introduction-ext4-filesystem#comments +[33]:https://opensource.com/users/dboth From ec3c7e37214d358f159a444d11f4634a07c9463c Mon Sep 17 00:00:00 2001 From: cinlen_0x05 <237448382@qq.com> Date: Sat, 24 Jun 2017 23:30:20 +0800 Subject: [PATCH 15/17] remove the bullet symbol --- ...introduction to Linux s EXT4 filesystem.md | 38 +++++++++---------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/translated/tech/20170525 An introduction to Linux s EXT4 filesystem.md b/translated/tech/20170525 An introduction to Linux s EXT4 filesystem.md index 3bbd63ff73..25e27d187e 100644 --- a/translated/tech/20170525 An introduction to Linux s EXT4 filesystem.md +++ b/translated/tech/20170525 An introduction to Linux s EXT4 filesystem.md @@ -1,7 +1,7 @@ Linux 的 EXT4 文件系统简介 ============================================================ -### 让我们大概地从 EXT4 的历史、特性以及最佳实践这几个方面来学习它和之前的所有的 EXT 文件系统有何不同。 +### 让我们大概地从 EXT4 的历史、特性以及最佳实践这几个方面来学习它和之前的所有的 EXT 文件系统有何不同。 ![An introduction to the EXT4 filesystem](https://opensource.com/sites/default/files/styles/image-full-size/public/images/life/hard_drives.png?itok=yZWyaSO6 "An introduction to the EXT4 filesystem") >图片来自 : [WIlliam][8][ Warby][9]. 由 [Jason Baker][10] 编辑. Creative Commons [BY-SA 2.0][11]. @@ -10,7 +10,7 @@ Linux 的 EXT4 文件系统简介 1. **数据存储:** 对于任何一个文件系统来说，一个最主要的功能就是能够被当作一个容器结构来存储和恢复数据。 -2. **命名空间:** 命名空间是一个提供了命名规则和数据结构的用于命名与组织的方法学。 +2. **命名空间:** 命名空间是一个提供了命名规则和数据结构的用于命名与组织的方法学。 3. **安全模型:** 一个用于定义访问权限的策略。 @@ -18,7 +18,7 @@ Linux 的 EXT4 文件系统简介 5. **实现:** 能够实现以上几点的软件。 -本文内容的讨论主要集中于上述几点中的第一项并探索为一个 EXT 文件系统的数据存储提供逻辑框架的元数据结构。 +本文内容的讨论主要集中于上述几点中的第一项并探索为一个 EXT 文件系统的数据存储提供逻辑框架的元数据结构。 ### EXT 文件系统历史 @@ -32,9 +32,9 @@ Minix 有以下这些结构，其中的大部分位于生成文件系统的分 * [**boot 扇区**][6] 是硬盘驱动安装后的第一个扇区。这个 boot 块包含了一个非常小的 boot 记录和一个分区表。 -* 每一个分区的第一个块都是一个包含了元数据的 **superblock** ，这些元数据定义了其他文件系统的结构并将其定位于物理硬盘的具体分区上。 +* 每一个分区的第一个块都是一个包含了元数据的 **superblock** ，这些元数据定义了其他文件系统的结构并将其定位于物理硬盘的具体分区上。 -* 一个 **inode 位图块** 决定了哪些 inode 是在使用中的，哪一些是未使用的。 +* 一个 **inode 位图块** 决定了哪些 inode 是在使用中的，哪一些是未使用的。 * **inode** 在硬盘上有它们自己的空间。每一个 inode 都包含了一个文件的信息包括其所处的数据块的位置，也就是该文件所处的区域。 @@ -44,19 +44,19 @@ Minix 有以下这些结构，其中的大部分位于生成文件系统的分 对上述了两种位图类型来说，一个 bit 表示一个制定的数据区或者一个指定的 inode. 如果这个 bit 是 0 则表示这个数据区或者这个 inode 是可以使用的，如果是 1 则表示正在使用中。 -那么，[inode][17] 又是什么呢 ? 就是 index-node (索引节点)的简写。 inode 是位于磁盘上的一个 256 字节的块，用于存储和该 inode 对应的文件的相关数据。这些数据包含了文件的大小、文件的所有者和所属组的用户的 ID、文件模式（即访问权限）以及三个时间戳用于指定：该文件最后的访问时间、该文件的最后修改时间和该 inode 中的数据的最后修改时间。 +那么，[inode][17] 又是什么呢 ? 就是 index-node (索引节点)的简写。 inode 是位于磁盘上的一个 256 字节的块，用于存储和该 inode 对应的文件的相关数据。这些数据包含了文件的大小、文件的所有者和所属组的用户的 ID、文件模式（即访问权限）以及三个时间戳用于指定：该文件最后的访问时间、该文件的最后修改时间和该 inode 中的数据的最后修改时间。 同时，这个 inode 还包含了指向了其所对应的文件的数据在硬盘中的位置。在 Minix 和 EXT1-3 文件系统中，inode 表示的是一系列的的数据区和块。Minix 文件系统的 inode 支持 9 个数据块包括 7 个直接数据块和 2 个间接数据块。如果你想要更深入的了解，这里有一个优秀的 PDF 详细地描述了 [Minix 文件系统街头][18] 。同时你也可以在维基百科上对 [inode 指针结构][19] 做一个快速的浏览。 ### EXT -原生的 [EXT 文件系统][20] (指经过扩展的) 是由 [Rémy Card][21] 编写并于 1992 年与 Linux 一同发行。主要是为了克服 Minix 文件系统中的一些文件大小限制的问题。其中，最主要的结构变化就是文件系统中的元数据。它基于 Unix 文件系统 （UFS），也被称为伯克利快速文件系统（FFS）。我发现只有很少一部分关于 EXT 文件系统的发行信息是可以被验证的，显然这是因为其存在着严重的问题并且它很快地被 EXT2 文件系统取代了。 +原生的 [EXT 文件系统][20] (指经过扩展的) 是由 [Rémy Card][21] 编写并于 1992 年与 Linux 一同发行。主要是为了克服 Minix 文件系统中的一些文件大小限制的问题。其中，最主要的结构变化就是文件系统中的元数据。它基于 Unix 文件系统 （UFS），也被称为伯克利快速文件系统（FFS）。我发现只有很少一部分关于 EXT 文件系统的发行信息是可以被验证的，显然这是因为其存在着严重的问题并且它很快地被 EXT2 文件系统取代了。 ### EXT2 [EXT2 文件系统][22] 就相当地成功，它在 Linux 发行版中存活了多年。它是我在 1997 年开始使用 Red Hat Linux 时认识的第一个文件系统。实际上，EXT2 文件系统有着和 EXT 文件系统基本相同的元数据结构。然而 EXT2 更高瞻远瞩，因为其元数据结构之间留有很多磁盘空间供将来使用。 -和 Minix 类似，EXT2 也有一个[boot 扇区][23] ，它是硬盘驱动安装后的第一个扇区。它包含了少量的 boot 记录和一个分区表。接着 boot 扇区之后是一些保留的空间，它跨越引导记录和通常位于下一个柱面的硬盘驱动器上的第一个分区之间的空间。 [GRUB2] [24] - 也可能是GRUB1 - 将此空间用于其部分启动代码。 +和 Minix 类似，EXT2 也有一个[boot 扇区][23] ，它是硬盘驱动安装后的第一个扇区。它包含了少量的 boot 记录和一个分区表。接着 boot 扇区之后是一些保留的空间，它跨越引导记录和通常位于下一个柱面的硬盘驱动器上的第一个分区之间的空间。 [GRUB2] [24] - 也可能是GRUB1 - 将此空间用于其部分启动代码。 每个 EXT2 分区中的空间分为各柱面组，它允许更精细地管理数据空间。 根据我的经验，每一组大小通常约为8MB。 下面的图1显示了一个柱面组的基本结构。 柱面中的数据分配单元是块，通常大小为4K。 @@ -150,21 +150,21 @@ Group 3: (Blocks 98304-131071) ``` -每一个柱面组都有自己的 inode 位图用于判定该柱面组中的哪些 inode 是使用中的而哪些又是未被使用的。每一个柱面组的 inode 都有它们自己的空间。每一个 inode 都包含了对应的文件的相关信息，包括其位于该文件的数据块中的位置。这个块位图纪录了文件系统中的使用中和非使用中的数据块。请注意，在上面的输出中有大量关于文件系统的数据。在非常大的文件系统上，组数据可以运行到数百页的长度。 组元数据包括组中所有空闲数据块的列表。 +每一个柱面组都有自己的 inode 位图用于判定该柱面组中的哪些 inode 是使用中的而哪些又是未被使用的。每一个柱面组的 inode 都有它们自己的空间。每一个 inode 都包含了对应的文件的相关信息，包括其位于该文件的数据块中的位置。这个块位图纪录了文件系统中的使用中和非使用中的数据块。请注意，在上面的输出中有大量关于文件系统的数据。在非常大的文件系统上，组数据可以运行到数百页的长度。 组元数据包括组中所有空闲数据块的列表。 EXT 文件系统实现了数据分配策略以确保产生最少的文件碎片。减少文件碎片可以提高文件系统的性能。这些策略会在下面的 EXT4 中描述到。 -我所遇见的关于 EXT2 文件系统最大的问题是 **fsck** (文件系统检查) 程序这一环节占用了很长一段时间来定位和校准文件系统中的所有不一致性导致其共花费了数个小时来修复一个崩溃。有一次我的其中一台电脑共花费了 28 个小时在一次崩溃后重新启动时恢复磁盘上，并且是在磁盘被检测量在几百兆字节大小的情况下。 +我所遇见的关于 EXT2 文件系统最大的问题是 **fsck** (文件系统检查) 程序这一环节占用了很长一段时间来定位和校准文件系统中的所有不一致性导致其共花费了数个小时来修复一个崩溃。有一次我的其中一台电脑共花费了 28 个小时在一次崩溃后重新启动时恢复磁盘上，并且是在磁盘被检测量在几百兆字节大小的情况下。 ### EXT3 [EXT3 文件系统][25] 具有克服 **fsck** 程序需要完全恢复在文件更新操作期间发生的不正确关机损坏的磁盘结构所需的大量时间的单一目标。EXT 文件系统的唯一新增是 [日志][26]，它将提前记录将对文件系统执行的更改。 磁盘结构的其余部分与 EXT2 中的相同。 -作为一个先前的版本，除了直接写入数据到磁盘的数据区域外，EXT3 的日志在写入元数据时同时会也写入文件数据到磁盘上的一个指定数据区域。一旦这些数据安全地到达硬盘，它就可以几乎零丢失率地被合并或者被追加到目标文件。当这些数据被提交到磁盘上的数据区域上，这些日志就会随即更新，这样在系统发生故障之前，文件系统将保持一致状态，才能提交日志中的所有数据。在下次启动时，将检查文件系统的不一致性，然后将日志中保留的数据提交到磁盘的数据区，以完成对目标文件的更新。 +作为一个先前的版本，除了直接写入数据到磁盘的数据区域外，EXT3 的日志在写入元数据时同时会也写入文件数据到磁盘上的一个指定数据区域。一旦这些数据安全地到达硬盘，它就可以几乎零丢失率地被合并或者被追加到目标文件。当这些数据被提交到磁盘上的数据区域上，这些日志就会随即更新，这样在系统发生故障之前，文件系统将保持一致状态，才能提交日志中的所有数据。在下次启动时，将检查文件系统的不一致性，然后将日志中保留的数据提交到磁盘的数据区，以完成对目标文件的更新。 日记功能确实降低了数据写入性能，但是有三个可用于日志的选项，允许用户在性能和数据完整性和安全性之间进行选择。 我的个人更偏向于选择安全性，因为我的环境不需要大量的磁盘写入活动。 -日志功能减少了在从几小时（甚至几天）到几分钟之间的失败后检查硬盘驱动器所需的时间。 多年来，我遇到了很多问题导致了我的系统崩溃。 要详细说的话恐怕还得再写一篇文章，但这足以说明大多数是我自己造成的，就比如不小心踢掉一个电源插头。 幸运的是，EXT日志文件系统将启动恢复时间缩短到两三分钟。 此外，自从我开始使用带日志记录的EXT3，我从来没有遇到丢失数据的问题。 +日志功能减少了在从几小时（甚至几天）到几分钟之间的失败后检查硬盘驱动器所需的时间。 多年来，我遇到了很多问题导致了我的系统崩溃。要详细说的话恐怕还得再写一篇文章，但这足以说明大多数是我自己造成的，就比如不小心踢掉一个电源插头。 幸运的是，EXT日志文件系统将启动恢复时间缩短到两三分钟。 此外，自从我开始使用带日志记录的EXT3，我从来没有遇到丢失数据的问题。 EXT3 的日志功能可以关闭，然后作为 EXT2 文件系统。 该日志本身仍然是存在的，只是状态为空且未使用。 只需使用类型参数使用 mount 命令来 remount 到分区即可指定EXT2 \。 你可以从命令行执行此操作，但是具体还是取决于你正在使用的文件系统，但你可以更改 **/ etc / fstab** 文件中的类型说明符，然后重新启动。 我强烈建议不要将 EXT3文件系统安装为 EXT2 ，因为这会具有丢失数据和增加恢复时间的潜在可能性。 @@ -174,15 +174,15 @@ EXT2 文件系统可以使用如下命令来通过日志升级到 EXT3 。 tune2fs -j /dev/sda1 ``` - **/dev/sda1** 表示驱动和分区的标识符。同时要注意修改 **/etc/fstab** 中的文件类型标识符并 remount 分区或者重启系统以确保修改生效。 + **/dev/sda1** 表示驱动和分区的标识符。同时要注意修改 **/etc/fstab** 中的文件类型标识符并 remount 分区或者重启系统以确保修改生效。 ### EXT4 -[EXT4 filesystem][27]主要提高了性能、可靠性和容量。位了提高可靠性，它新增了元数据和日志校验和。同时位了满足各种关键任务要求，文件系统新增了纳秒级别的时间戳。在时间戳字段中添加两个高位来延迟时间戳的 [2038 年的问题][28] ，在 EXT4 文件系统至少可达到 2446 年。 +[EXT4 filesystem][27]主要提高了性能、可靠性和容量。位了提高可靠性，它新增了元数据和日志校验和。同时位了满足各种关键任务要求，文件系统新增了纳秒级别的时间戳。在时间戳字段中添加两个高位来延迟时间戳的 [2038 年的问题][28] ，在 EXT4 文件系统至少可达到 2446 年。 在 EXT4 中，数据分配从固定块更改为盘区，盘区由硬盘驱动器上的开始和结束位置来描述。这使得可以在单个 inode 指针条目中描述非常长的物理连续的文件，这可以显着减少描述大文件中所有数据的位置所需的指针数。 EXT4 中已经实施了其他分配策略，以进一步减少碎片化。 -EXT4 通过将新创建的文件分散在磁盘上，从而使其不会全部聚集在磁盘起始位置，就像早期的PC文件系统一样，减少了碎片。文件分配算法尝试在柱面组中尽可能均匀地扩展文件，并且当需要分段时，要使不连续文件扩展区尽可能靠近同一文件中的其他文件，以尽可能减少头部搜索和旋转等待时间尽可能的当创建新文件或扩展现有文件时，使用其他策略来预分配额外的磁盘空间。这有助于确保扩展文件不会自动导致其分段。新文件不会在现有文件之后立即分配，这也可以防止现有文件的碎片化。 +EXT4 通过将新创建的文件分散在磁盘上，从而使其不会全部聚集在磁盘起始位置，就像早期的PC文件系统一样，减少了碎片。文件分配算法尝试在柱面组中尽可能均匀地扩展文件，并且当需要分段时，要使不连续文件扩展区尽可能靠近同一文件中的其他文件，以尽可能减少头部搜索和旋转等待时间尽可能的当创建新文件或扩展现有文件时，使用其他策略来预分配额外的磁盘空间。这有助于确保扩展文件不会自动导致其分段。新文件不会在现有文件之后立即分配，这也可以防止现有文件的碎片化。 除了磁盘上数据的实际位置外，EXT4 使用诸如延迟分配的功能策略，以允许文件系统在分配空间之前收集正在写入磁盘的所有数据。这可以提高数据空间将是连续的可能性。 @@ -206,7 +206,7 @@ inod e包含有关该文件的元数据，包括其类型和权限以及其大 ### 数据碎片 -对于许多较旧的 PC 文件系统，如 FAT（及其所有变体）和 NTFS，碎片一直是导致磁盘性能下降的重大问题。 碎片整理对于其本身和一些专门的整理软件来说已经称为了一项专门的工程，其效果范围从非常有效到仅仅是微乎其微。 +对于许多较旧的 PC 文件系统，如 FAT（及其所有变体）和 NTFS，碎片一直是导致磁盘性能下降的重大问题。 碎片整理对于其本身和一些专门的整理软件来说已经称为了一项专门的工程，其效果范围从非常有效到仅仅是微乎其微。 Linux 的扩展文件系统使用数据分配策略，有助于最小化硬盘驱动器上的文件碎片，并在发生碎片时减少碎片的影响。 你可以使用 EXT 文件系统上的 **fsck** 命令检查文件系统的整体碎片。 以下示例检查主工作站的主目录，只有 1.5％ 的碎片。 确保使用 **- n** 参数，因为它会阻止 **fsck** 对扫描文件系统采取的任何操作。 @@ -241,13 +241,13 @@ fsck -fn /dev/mapper/vg_01-home 这并不是说一些应用的环境不需要更多的保证，甚至更少的碎片。 EXT 文件系统可以由有经验和知识的管理员小心调整，管理员可以调整参数以抵消特定的工作负载类型。这个工作可以在文件系统创建的时候或稍后使用 **tune2fs** 命令时完成。每一次调整变化的结果应进行测试，精心的记录和分析，以确保目标环境的最佳性能。在最坏的情况下，如果性能不能提高到期望的水平，则其他文件系统类型可能更适合特定的工作负载。并记住，在单个主机系统上使用混合文件系统类型以匹配放在每个文件系统上的负载是常见的。 -由于大多数 EXT 文件系统的碎片数量较少，因此无需进行碎片整理。在任何情况下，EXT 文件系统都没有安全的碎片整理工具。有几个工具允许你检查单个文件的碎片或文件系统中剩余可用空间的碎片。有一个工具，**e4defrag**，它将对剩余可用空间允许的文件，目录或文件系统进行碎片整理。顾名思义，它只适用于 EXT4 文件系统中的文件，并且它还有一其它的些限制。 +由于大多数 EXT 文件系统的碎片数量较少，因此无需进行碎片整理。在任何情况下，EXT 文件系统都没有安全的碎片整理工具。有几个工具允许你检查单个文件的碎片或文件系统中剩余可用空间的碎片。有一个工具，**e4defrag**，它将对剩余可用空间允许的文件，目录或文件系统进行碎片整理。顾名思义，它只适用于 EXT4 文件系统中的文件，并且它还有一其它的些限制。 -如果有必要在 EXT 文件系统上执行完整的碎片整理，则只有一种方法能够可靠地工作。你必须将文件系统中的所有要进行碎片整理的文件在确保在安全复制到其他位置后将其删除。如果可能，你可以增加文件系统的大小，以帮助减少将来的碎片。然后将文件复制回目标文件系统。但是其实即使这样也不能保证所有文件都被完全碎片整理。 +如果有必要在 EXT 文件系统上执行完整的碎片整理，则只有一种方法能够可靠地工作。你必须将文件系统中的所有要进行碎片整理的文件在确保在安全复制到其他位置后将其删除。如果可能，你可以增加文件系统的大小，以帮助减少将来的碎片。然后将文件复制回目标文件系统。但是其实即使这样也不能保证所有文件都被完全碎片整理。 ### 总结 -EXT 文件系统在一些 Linux 发行版本上作为默认文件系统已经超过二十多年了。它们用最少的维护代价提供了稳定性、高可用性、可靠性和其他各种表现。我尝试过一些其它的文件系统但最终都还是回归到 EXT。每一个我在工作中使用到 Linux 的地方都使用到了 EXT 文件系统，同时发现了它们适用于任何主流的负载。毫无疑问，EXT4 文件系统应该被用于大部分的 Linux 文件系统上，除非我们有明显的使用其它文件系统的理由。 +EXT 文件系统在一些 Linux 发行版本上作为默认文件系统已经超过二十多年了。它们用最少的维护代价提供了稳定性、高可用性、可靠性和其他各种表现。我尝试过一些其它的文件系统但最终都还是回归到 EXT。每一个我在工作中使用到 Linux 的地方都使用到了 EXT 文件系统，同时发现了它们适用于任何主流的负载。毫无疑问，EXT4 文件系统应该被用于大部分的 Linux 文件系统上，除非我们有明显的使用其它文件系统的理由。 -------------------------------------------------------------------------------- From bcb9a1280ebfb78b743e04c4525b197751c2146b Mon Sep 17 00:00:00 2001 From: cinlen_0x05 <237448382@qq.com> Date: Sun, 25 Jun 2017 11:25:29 +0800 Subject: [PATCH 16/17] translating by chenxinlong --- .../20170623 A introduction to creating documents in LaTeX.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/sources/tech/20170623 A introduction to creating documents in LaTeX.md b/sources/tech/20170623 A introduction to creating documents in LaTeX.md index 498c0f45ce..61df7bc579 100644 --- a/sources/tech/20170623 A introduction to creating documents in LaTeX.md +++ b/sources/tech/20170623 A introduction to creating documents in LaTeX.md @@ -1,3 +1,4 @@ +translating by chenxinlong A introduction to creating documents in LaTeX ============================================================ @@ -126,7 +127,7 @@ Aaron Cocker - BSc Computing student attending university in the UK. I am an asp via: https://opensource.com/article/17/6/introduction-latex 作者：[ Aaron Cocker][a] -译者：[译者ID](https://github.com/译者ID) +译者：[chenxinlong](https://github.com/chenxinlong) 校对：[校对者ID](https://github.com/校对者ID) 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 From 7903ec284ed0badc1b21fa389178a6914932228f Mon Sep 17 00:00:00 2001 From: chenxinlong <237448382@qq.com> Date: Sun, 25 Jun 2017 13:07:30 +0800 Subject: [PATCH 17/17] =?UTF-8?q?=E7=BF=BB=E8=AF=91=E5=AE=8C=E6=88=90?= =?UTF-8?q?=E5=B9=B6=E7=94=B3=E8=AF=B7=E5=8F=A6=E4=B8=80=E7=AF=87=E6=96=87?= =?UTF-8?q?=E7=AB=A0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...in Ubuntu LinuxMint With Ubuntu Cleaner.md | 4 +- ...oduction to creating documents in LaTeX.md | 150 ------------------ ...oduction to creating documents in LaTeX.md | 149 +++++++++++++++++ 3 files changed, 152 insertions(+), 151 deletions(-) delete mode 100644 sources/tech/20170623 A introduction to creating documents in LaTeX.md create mode 100644 translated/tech/20170623 A introduction to creating documents in LaTeX.md diff --git a/sources/tech/20170622 Free Up Some Space in Ubuntu LinuxMint With Ubuntu Cleaner.md b/sources/tech/20170622 Free Up Some Space in Ubuntu LinuxMint With Ubuntu Cleaner.md index f6eb3f846e..fd04eb6e71 100644 --- a/sources/tech/20170622 Free Up Some Space in Ubuntu LinuxMint With Ubuntu Cleaner.md +++ b/sources/tech/20170622 Free Up Some Space in Ubuntu LinuxMint With Ubuntu Cleaner.md @@ -1,3 +1,5 @@ +translating by chenxinlong + Free Up Some Space in Ubuntu/LinuxMint With Ubuntu Cleaner (Fork of Janitor Module) ============================================================ @@ -60,7 +62,7 @@ Yes, we have successfully cleaned our system now. via: http://www.2daygeek.com/ubuntu-cleaner-system-cleaner-ubuntu-tweak-alternative-janitor/# 作者：[2DAYGEEK ][a] -译者：[译者ID](https://github.com/译者ID) +译者：[chenxinlong](https://github.com/chenxinlong) 校对：[校对者ID](https://github.com/校对者ID) 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 diff --git a/sources/tech/20170623 A introduction to creating documents in LaTeX.md b/sources/tech/20170623 A introduction to creating documents in LaTeX.md deleted file mode 100644 index 61df7bc579..0000000000 --- a/sources/tech/20170623 A introduction to creating documents in LaTeX.md +++ /dev/null @@ -1,150 +0,0 @@ -translating by chenxinlong -A introduction to creating documents in LaTeX -============================================================ - -### Learn to typeset documents in the LaTeX text markup language. - -![A introduction to creating documents in LaTeX](https://opensource.com/sites/default/files/styles/image-full-size/public/images/life/idea_innovation_kid_education.png?itok=jpetC9wJ "A introduction to creating documents in LaTeX") -Image by : opensource.com - -LaTeX (pronounced  _lay-tech_ ) is a method of creating documents using plain text, stylized using markup tags, similar to HTML/CSS or Markdown. LaTeX is most commonly used to create documents for academia, such as academic journals. In LaTeX, the author doesn't stylize the document directly, like in a word processor such as Microsoft Word, LibreOffice Writer, or Apple Pages; instead they write code in plain text that must be compiled to produce a PDF document. - -### [intro.png][1] - -![computer screen with LaTeX markup language](https://opensource.com/sites/default/files/u128651/intro.png "computer screen with LaTeX markup language") - -### How to get started - -To write in LaTeX, you'll need to install a LaTeX editor. I use a piece of free and open source software (FOSS) popular with academics called [TexStudio][8], which runs on Windows, Unix/Linux, BSD, and Mac OS X. You'll also need to install a distribution of the **Tex** typesetting system. I am writing on MacOS, so I use a distribution called [MacTex or BasicTex][9]. For Windows you can use [MiKTex][10], and Linux users should be able to find it in their repository. - -Once you have downloaded TexStudio and a distribution of LaTeX, you should be ready to start typesetting your documents. - -### Create your first document - -In this short tutorial, we'll create a simple article with a headline, a subhead, and two paragraphs. - -After you launch TexStudio, save your new document. (I called mine **helloworld.tex**, since I'm writing this tutorial in the Hello, World! tradition from programming.) Next, you need to add some boilerplate code at the top of your **.tex** file that specifies the type and size of your document. This is similar to the boilerplate code used in HTML5 documents. - -My code (below) sets the page size to A4 and the text size to 12pt. You can put this code into TexStudio and edit it with your own page size, font size, name, title, and other details: - -``` -\documentclass[a4paper,12pt]{article} -\begin{document} -\title{Hello World! My first LaTeX document} -\author{Aaron Cocker} -\date{\today} -\maketitle - -content will go here - -\end{document} -``` - -Next, click on the large green arrow to compile the document. That's the middle button in the screenshot below. - -### [compile.png][2] - -![compile button in TexStudio](https://opensource.com/sites/default/files/u128651/compile.png "compile button in TexStudio") - -If there are any errors, they'll appear in the dialog box at the bottom. - -After you compile the document, you can see what it will look like by viewing a PDF within the program as a sort of WYSIWYG preview. Remember it must be recompiled whenever you make a change to the code, as you would when programming in C++, for example. - -To view your document, click on **Tools > Commands > View PDF**, as shown in the screenshot below. - -### [view_as_pdf.png][3] - -![Menu to view a PDF](https://opensource.com/sites/default/files/u128651/view_as_pdf.png "Menu to view a PDF") - -The PDF output will be shown on the right, like this: - -### [pdf_output.png][4] - -![Viewing the LaTeX code as PDF](https://opensource.com/sites/default/files/u128651/pdf_output.png "Viewing the LaTeX code as PDF") - -Now you can add a paragraph. First give it a subhead by using the **\section{}**command. Type the subhead title between the curly braces of the command; I called my subhead **Introduction**. - -``` -\section{Introduction} -``` - -Now that you have labeled the paragraph with its subhead, it's time to write the paragraph. For this example, I used the Lipsum [lorem ipsum generator][11]. To create the paragraph, type the **\paragraph{}** command, then add your text  _underneath_ ,  _NOT within_ , the curly braces, inserted between **\maketitle** and **\end{document}**. - -This is what my paragraph code looks like: - -``` -\section{Introduction} - -\paragraph{} -Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras lorem nisi, tincidunt tempus sem nec, elementum feugiat ipsum. Nulla in diam libero. Nunc tristique ex a nibh egestas sollicitudin. - -\paragraph{} -Mauris efficitur vitae ex id egestas. Vestibulum ligula felis, pulvinar a posuere id, luctus vitae leo. Sed ac imperdiet orci, non elementum leo. Nullam molestie congue placerat. Phasellus tempor et libero maximus commodo. -``` - -Your document is now finished, so you can export and save it as a PDF file by using **Save As** (just as you would with most programs). - -Here's what my finished document and the corresponding code look like: - -### [finished_document.png][5] - -![The finished document with code and the PDF output side-by-side](https://opensource.com/sites/default/files/u128651/finished_document.png "The finished document with code and the PDF output side-by-side") - -All my code from this tutorial is available below: - -``` -\documentclass[a4paper,12pt]{article} -\begin{document} -\title{Hello World! My first LaTeX document} -\author{Aaron Cocker} -\date{\today} -\maketitle - -\section{Introduction} - -\paragraph{} -Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras lorem nisi, tincidunt tempus sem nec, elementum feugiat ipsum. Nulla in diam libero. Nunc tristique ex a nibh egestas sollicitudin. - -\paragraph{} -Mauris efficitur vitae ex id egestas. Vestibulum ligula felis, pulvinar a posuere id, luctus vitae leo. Sed ac imperdiet orci, non elementum leo. Nullam molestie congue placerat. Phasellus tempor et libero maximus commodo. - -\end{document} -``` - -### Learn more - -Among the thousands of excellent resources on writing in LaTeX are the guides produced by most universities, which are indexable and can be found on Google search. [Princeton University][12] offers a good extended tutorial, and for a deeper dive, the Princeton guide's creator, Donald Knuth, offers [The TexBook][13], the ultimate guide to LaTeX. - --------------------------------------------------------------------------------- - -作者简介： - -Aaron Cocker - BSc Computing student attending university in the UK. I am an aspiring Data Scientist. My favourite language is Python. Feel free to contact me at aaron@aaroncocker.org.uk or visit my personal website: https://aaroncocker.org.uk - - ---------------- - -via: https://opensource.com/article/17/6/introduction-latex - -作者：[ Aaron Cocker][a] -译者：[chenxinlong](https://github.com/chenxinlong) -校对：[校对者ID](https://github.com/校对者ID) - -本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 - -[a]:https://opensource.com/users/aaroncocker -[1]:https://opensource.com/file/356521 -[2]:https://opensource.com/file/356526 -[3]:https://opensource.com/file/356541 -[4]:https://opensource.com/file/356536 -[5]:https://opensource.com/file/356531 -[6]:https://opensource.com/article/17/6/introduction-latex?rate=n5CmhY55ZhQRMjd6n5-f2p9f7iGg0nAWh_Bi6jqMMyc -[7]:https://opensource.com/user/123226/feed -[8]:http://www.texstudio.org/ -[9]:https://www.tug.org/mactex/morepackages.html -[10]:https://miktex.org/download -[11]:http://www.lipsum.com/feed/html -[12]:https://www.cs.princeton.edu/courses/archive/spr10/cos433/Latex/latex-guide.pdf -[13]:http://www.ctex.org/documents/shredder/src/texbook.pdf -[14]:https://opensource.com/users/aaroncocker -[15]:https://opensource.com/article/17/6/introduction-latex#comments diff --git a/translated/tech/20170623 A introduction to creating documents in LaTeX.md b/translated/tech/20170623 A introduction to creating documents in LaTeX.md new file mode 100644 index 0000000000..cb5cf9e3cf --- /dev/null +++ b/translated/tech/20170623 A introduction to creating documents in LaTeX.md @@ -0,0 +1,149 @@ +如何在 LaTex 中创建文档 +============================================================ + +### 学习以 LaTex 文本标记语言排版文档 + +![A introduction to creating documents in LaTeX](https://opensource.com/sites/default/files/styles/image-full-size/public/images/life/idea_innovation_kid_education.png?itok=jpetC9wJ "A introduction to creating documents in LaTeX") +图片来自 : opensource.com + +LaTeX（读作_lay-tech_）是使用纯文本创建文档的方法，使用与 HTML/CSS 或 Markdown 类似的标记标签进行风格化。 LaTeX 最常用于为学术界（如学术期刊）创建文档。 在 LaTeX 中，作者不必直接对文档进行风格化，例如 Microsoft Word，LibreOffice Writer 或 Apple Page s等文字处理程序； 而是用纯文本编写代码，这些代码必须被编译才能生成 PDF 文档。 + +### [intro.png][1] +r +![computer screen with LaTeX markup language](https://opensource.com/sites/default/files/u128651/intro.png "computer screen with LaTeX markup language") + +### 起步 + +要想使用 LaTex 来书写文档，首先你必须要安装一个 LaTex 编辑器。我用的是一款免费且开源，同时在学术界也是大受欢迎的软件叫做 [TexStudio][8], 它可以运行在 Windows、Unix/Linux、BSD 和 Mac OS X 上。同时你还需要安装一个 **Tex** 排版系统的发行版。因为我斗士在 MacOS 上书写文档，所以我使用的发行版本是 [MacTex or BasicTex][9]。对于 Windows 用户你可以使用[MiKTex][10]，而且 Linux 用户也可以在 repository 中找到它。 + +当你完成了 TexStudio 和 LaTex 发行版的下载，你就可以开始对你的文档进行排版了。 + +### 创建你的第一个文档 + +在这个简短的教程里，我们会创建一个简单的文章包括一个大标题、一个子标题和两个段落。 + +在启动 TexStudio后，保存一份新的文档。 （我将其保存为 **helloworld.tex** ，因为我正在编写本教程的 Hello，World！文档。这是编程的一个传统。）接下来，你需要在你的 **.txt** 文件顶部添加一些样板代码用于指定文档的类型和大小。 这与 HTML5 w文件中使用的样板代码类似。 + +我的代码（下方）将会把页面大小设置为 A4，文本大小设置为 12 pt 。 你可以直接把这些代码放入 TexStudio，并指定你自己的页面大小，字体大小，名称，标题和其他详细信息进行编辑： + +``` +\documentclass[a4paper,12pt]{article} +\begin{document} +\title{Hello World! My first LaTeX document} +\author{Aaron Cocker} +\date{\today} +\maketitle + +content will go here + +\end{document} +``` + +接下来，点击那个大的绿色箭头来编译该文档。就是下方截图中的中间的那个按钮。 + +### [compile.png][2] + +![compile button in TexStudio](https://opensource.com/sites/default/files/u128651/compile.png "compile button in TexStudio") + +如果这期间发生了什么错误，它将显示在底部的对话框里。 + +在你编译了这个文档之后，你可以看到它就像一个 PDF 一样显示在程序的 WYSIWYG (所见即所得) 预览区域中。记住一旦你修改了代码就必须重新编译，就像我们在 C++ 中编程一样。 + +通过点击 **Tools > Commands > View PDF** 可以来预览你的文档，如下截图所示。 + +### [view_as_pdf.png][3] + +![Menu to view a PDF](https://opensource.com/sites/default/files/u128651/view_as_pdf.png "Menu to view a PDF") + +PDF 的输出将会显示在右侧，就像这样： + +### [pdf_output.png][4] + +![Viewing the LaTeX code as PDF](https://opensource.com/sites/default/files/u128651/pdf_output.png "Viewing the LaTeX code as PDF") + +现在你可以添加一个段落。首先先通过 **\section{}** 命令来写一个子标题。在命令的大括号中输入你的子标题；我写的是 **Introduction**. + +``` +\section{Introduction} +``` + +现在你已经给你的段落标记了一个子标题，是时候来写一个段落了。在这个例子中，我使用了 Lipsum [lorem ipsum 生成器][11]。要创建一个段落，要使用 **\paragraph{}** 命令， 将你的文本插入到 **\maketitle** 和 **\end{document}** 之间的的 **\paragraph{}** 大括号下方，而不是中间。 + +以下就是我创建的段落的代码： + +``` +\section{Introduction} + +\paragraph{} +Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras lorem nisi, tincidunt tempus sem nec, elementum feugiat ipsum. Nulla in diam libero. Nunc tristique ex a nibh egestas sollicitudin. + +\paragraph{} +Mauris efficitur vitae ex id egestas. Vestibulum ligula felis, pulvinar a posuere id, luctus vitae leo. Sed ac imperdiet orci, non elementum leo. Nullam molestie congue placerat. Phasellus tempor et libero maximus commodo. +``` + +现在你的文档就已经完成了，你可以将其通过 **Save As** 选项导出并保存为一个 PDF 文档（和大多数程序一样）。 + +这是一个我已经完成的文档及其相应的代码： + +### [finished_document.png][5] + +![The finished document with code and the PDF output side-by-side](https://opensource.com/sites/default/files/u128651/finished_document.png "The finished document with code and the PDF output side-by-side") + +本教程所有的代码如下所示： + +``` +\documentclass[a4paper,12pt]{article} +\begin{document} +\title{Hello World! My first LaTeX document} +\author{Aaron Cocker} +\date{\today} +\maketitle + +\section{Introduction} + +\paragraph{} +Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras lorem nisi, tincidunt tempus sem nec, elementum feugiat ipsum. Nulla in diam libero. Nunc tristique ex a nibh egestas sollicitudin. + +\paragraph{} +Mauris efficitur vitae ex id egestas. Vestibulum ligula felis, pulvinar a posuere id, luctus vitae leo. Sed ac imperdiet orci, non elementum leo. Nullam molestie congue placerat. Phasellus tempor et libero maximus commodo. + +\end{document} +``` + +### 更多 + +在 LaTeX 撰写的数以千计的优秀资源中，大多数大学制作的指南是可索引的，同时也可以在 Google 搜索中找到。 [普林斯顿大学 University][12] 提供了一个很好的扩展教程，为了更深入的了解，普林斯顿大学的导师 Donald Knuth 提供了 [The TexBook][13]，这是关于 LaTeX 的最好的教程。 + +-------------------------------------------------------------------------------- + +作者简介： + +Aaron Cocker - 一名在英国上大学的计算机学士。我是一个有抱负的数据科学家。我最喜欢的语言是 Python。 你可以随时通过邮箱联系我 : aaron@aaroncocker.org.uk 或者访问我的个人网站 : https://aaroncocker.org.uk + + +--------------- + +via: https://opensource.com/article/17/6/introduction-latex + +作者：[ Aaron Cocker][a] +译者：[chenxinlong](https://github.com/chenxinlong) +校对：[校对者ID](https://github.com/校对者ID) + +本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 + +[a]:https://opensource.com/users/aaroncocker +[1]:https://opensource.com/file/356521 +[2]:https://opensource.com/file/356526 +[3]:https://opensource.com/file/356541 +[4]:https://opensource.com/file/356536 +[5]:https://opensource.com/file/356531 +[6]:https://opensource.com/article/17/6/introduction-latex?rate=n5CmhY55ZhQRMjd6n5-f2p9f7iGg0nAWh_Bi6jqMMyc +[7]:https://opensource.com/user/123226/feed +[8]:http://www.texstudio.org/ +[9]:https://www.tug.org/mactex/morepackages.html +[10]:https://miktex.org/download +[11]:http://www.lipsum.com/feed/html +[12]:https://www.cs.princeton.edu/courses/archive/spr10/cos433/Latex/latex-guide.pdf +[13]:http://www.ctex.org/documents/shredder/src/texbook.pdf +[14]:https://opensource.com/users/aaroncocker +[15]:https://opensource.com/article/17/6/introduction-latex#comments