linux论文英文参考文献

Anatomy of Linux flash file systemsOptions and architecturesSummary: You've probably heard of Journaling Flash File System (JFFS) and YetAnother Flash File System (YAFFS), but do you know what it means to have a filesystem that assumes an underlying flash device? This article introduces you toflash file systems for Linux®, explores how they care for their underlyingconsumable devices (flash parts) through wear leveling, and identifies thevarious flash file systems available along with their fundamental drives are all the rage these days, but embedded systems haveused solid-state devices for storage for quite some time. You'll find flashfile systems used in personal digital assistants (PDAs), cell phones, MP3players, digital cameras, USB flash drives (UFDs), and even laptop many cases, the file systems for commercial devices can be custom andproprietary, but they face the same challenges discussed below. Flash-based file systems come in a variety of forms. This article exploresa couple of the read-only file systems and also reviews the various read/writefile systems available today and how they work. But first, let's explore theflash devices and the challenges that they introduce. Flash memory technologiesFlash memory, which can come in several different technologies, is non-volatilememory, which means that its contents persist after its source of power isremoved. For a great history of flash memory devices, see of the most common types of flash devices are defined by theirrespective technologies: NOR and NAND. NOR-based flash is the older technologythat supported high read performance at the expense of smaller capacities. NANDflash offers higher capacities with significantly faster write and eraseperformance. NAND also requires a much more complicated input/output (I/O)interface. Flash parts are commonly divided into partitions, which allowsmultiple operations to occur simultaneously (erasing one partition whilereading from another). Partitions are further divided into blocks(commonly 64KB or 128KB in size). Firmware that uses the partitions can furtherapply unique segmenting to the blocks—for example, 512-byte segments within ablock, not including metadata. Flash devices exhibit a common constraint that requires device managementwhen compared to other storage devices such as RAM disks. The only Writeoperation permitted on a flash memory device is to change a bit from a one to azero. If the reverse operation is needed, then the block must be erased (toreset all bits to the one state). This means that other valid data within theblock must be moved for it to persist. NOR flash memory can typically beprogrammed a byte at a time, whereas NAND flash memory must be programmed inmulti-byte bursts (typically, 512 bytes). The process of erasing a block differs between the two memory types. Eachrequires a special Erase operation that covers an entire block of the flashmemory. NOR technology requires a precursor step to clear all values to zerobefore the Erase operation can begin. An Erase is a special operationwith the flash device and can be time-consuming. Erasing is an electricaloperation that drains the electrons from each cell in an entire block. NOR flash devices typically require seconds for the Erase operation,whereas a NAND device can erase in milliseconds. A key characteristic of flashdevices is the number of Erase operations that can be performed. In a NORdevice, each block in the flash memory can be erased up to 100,000 times. NANDflash memories can be erased up to one million times. Flash memory challengesIn addition to and as a result of the constraints explored in the previoussection, managing flash devices presents several challenges. The three mostimportant are garbage collection, managing bad blocks, and wear leveling. Garbage collectionGarbage collection is the process of reclaiming invalid blocks (those thatcontain some amount of invalid data). Reclamation involves moving the validdata to a new block, and then erasing the invalid block to make it process is commonly done in the background or as needed, if the filesystem is low on available space. Managing bad blocksOver time, flash devices can develop bad blocks through use and can evenship from the manufacturer with blocks that are bad and cannot be used. You candetect the presence of back blocks from a failed flash operation (such as anErase) or an invalid Write operation (discovered through an invalid ErrorCorrection Code, or ECC). After bad blocks have been identified, they are marked within the flashitself in a bad block table. How this is done is device-dependent but can beimplemented with a separate set of reserved blocks managed separately fromnormal data blocks. The process of handling bad blocks—whether they ship withthe device or appear over time—is called bad block management. In somecases, this functionality is implemented in hardware by an internalmicrocontroller and is therefore transparent to the upper-level file system. Wear levelingRecall that flash devices are consumable parts: You can perform a finitenumber of Erase cycles on each block before the block becomes bad (and musttherefore be tagged by bad block management). To maximize the life of theflash, wear-leveling algorithms are provided. Wear leveling comes in twovarieties: dynamic wear leveling and static wear leveling. Dynamic wear leveling addresses the problem of a limited number of Erasecycles for a given block. Rather than randomly using blocks as they areavailable, dynamic wear-leveling algorithms attempt to evenly distribute theuse of blocks so that each gets uniform use. Static wear-leveling algorithmsaddress an even more interesting problem. In addition to a maximum number ofErase cycles, certain flash devices suffer from a maximum number of Read cyclesbetween Erase cycles. This means that if data sits for too long in a block andis read too many times, the data can dissipate and result in data loss. Staticwear-leveling algorithms address this by periodically moving stale data to newblocks. System architectureSo far, I've explored flash devices and their fundamental challenges. Now,look at how these pieces come together as part of a layered architecture (seeFigure 1). At the top is the virtual file system (VFS), which presents a commoninterface to higher-level applications. The VFS is followed by the flash filesystem, which will be covered in the next section. Next is the FlashTranslation Layer (FTL), which provides for overall management of the flashdevice, including allocation of blocks from the underlying flash device as wellas address translation, dynamic wear leveling, and garbage collection. In someflash devices, a portion of the FTL can be implemented in hardware. The Linux kernel uses the Memory Technology Device (MTD) interface, whichis a generic interface for flash devices. The MTD can automatically detect thewidth of the flash device bus and the number of devices necessary forimplementing the bus width. Flash file systemsSeveral flash file systems are available for Linux. The next sectionsexplain the design and advantages of each. Journaling Flash File SystemOne of the earliest flash file systems for Linux is called the JournalingFlash File System. JFFS is a log-structured file system that was designedfor NOR flash devices. It was unique and addressed a variety of problems withflash devices, but it created another. JFFS viewed the flash device as a circular log of blocks. Data written tothe flash is written to the tail, and blocks at the head are reclaimed. Thespace between the tail and head is free space; when this space becomes low, thegarbage collector is executed. The garbage collector moves valid blocks to thetail of the log, skips invalid or obsolete blocks, and erases them (see Figure2). The result is a file system that is automatically wear leveled bothstatically and dynamically. The fundamental problem with this architecture isthat the flash device is erased too often (instead of an optimal erasestrategy), which wears the device out too quickly. When a JFFS is mounted, the structural details are read into memory, whichcan be slow at mount-time and consume more memory than desired. Journaling Flash File System 2Although JFFS was very useful in its time, its wear-leveling algorithmtended to shorten the life of NOR flash devices. The result was a redesign ofthe underlying algorithm to remove the circular log. The JFFS2 algorithm wasdesigned for NAND flash devices and also includes improved performance withcompression. In JFFS2, each block in the flash is treated independently. JFFS2 maintainsblock lists to sufficiently wear-level the device. The clean list representsblocks on the device that are full of valid nodes. The dirty list containsblocks with at least one obsoleted node. Finally, the free list represents theblocks that have been erased and are available for use. The garbage collection algorithm can then intelligently decide what toreclaim in a reasonable way. Currently, the algorithm probabilistically selectsfrom the clean or dirty list. The dirty list is selected 99 percent of the timeto reclaim blocks (moving the valid contents to another block), and the cleanlist is selected 1 percent of the time (simply moving the contents to a newblock). In both cases, the selected block is erased and placed on the free list(see Figure 3). This allows the garbage collector to re-use blocks that areobsoleted (or partially so) but still move data around the flash to supportstatic wear leveling. Yet Another Flash File SystemYAFFS is another flash file system developed for NAND flash. The initialversion (YAFFS) supported flash devices with 512-byte pages, but the newerversion (YAFFS2) supports newer devices with larger page sizes and greaterWrite constraints. In most flash file systems, obsolete blocks are marked as such, but YAFFS2additionally marks blocks with monotonically increasing sequence numbers. Whenthe file system is scanned at mount time, the valid inodes can be quicklyidentified. YAFFS also maintains trees in RAM to represent the block structureof the flash device, including fast mounting through checkpointing —theprocess of saving the RAM tree structure to the flash device on a normalunmount so that it can be quickly read and restored to RAM at mount time (seeFigure 4). Mount-time performance is a great advantage of YAFFS2 over otherflash file systems. Read-only compressed file systemsIn some embedded systems, there's no need to provide a mutable file system:An immutable one will suffice. Linux supports a variety of read-only filesystems, two of the most useful are cramfs and SquashFS. CramfsThe cramfs file system is a compressed read-only Linux file system that canexist within flash devices. The primary characteristics of cramfs are that itis both simple and space-efficient. This file system is used in small-footprintembedded designs. While cramfs metadata is not compressed, cramfs uses zlib compression on aper-page basis to allow random page access (pages are decompressed uponaccess). You can play with cramfs using the mkcramfs utility and the loopbackdevice. SquashFSSquashFS is another compressed read-only Linux file system that is usefulwithin flash devices. You'll also find SquashFS in numerous Live CD Linuxdistributions. In addition to supporting zlib for compression, SquashFS usesLembel-Ziv-Markov chain Algorithm (LZMA) for improved compression and speed. Like cramfs, you can use SquashFS on a standard Linux system withmksquashfs and the loopback device. Going furtherLike most of open source, software continues to evolve, and new flash filesystems are under development. An interesting alternative still in developmentis LogFS, which includes some very novel ideas. For example, LogFS maintains atree structure on the flash device itself so that the mount times are similarto traditional file systems, such as ext2. It also uses a wandering tree forgarbage collection (a form of B+tree). What makes LogFS particularlyinteresting, however, is that it is very scalable and can support large flashparts. With the growing popularity of flash file systems, you'll see aconsiderable amount of research being applied toward them. LogFS is oneexample, but other options, such as UbiFS, are also growing. Flash file systemsare interesting architecturally and will continue to be a source of innovationin the future.

英文引用及参考文献格式要求如下：

参考文献(即引文出处)的类型以单字母方式标识,具体如下:

M——专著C——论文集N——报纸文章

J——期刊文章D——学位论文R——报告

对于不属于上述的文献类型,采用字母“Z”标识。

对于英文参考文献,还应注意以下两点:

①作者姓名采用“姓在前名在后”原则,具体格式是:姓,名字的首字母.

如:MalcolmRichardCowley为:Cowley,.,

如果有两位作者,第一位作者方式不变,&之后第二位作者名字的首字母放在前面,姓放在后面,

如: FrankNorris与IrvingGordon应为:Norris,F.&.;

②书名、报刊名使用斜体字,如:MasteringEnglishLiterature, EnglishWeekly。

扩展资料：

参考文献类型及文献类型，根据GB3469-83《文献类型与文献载体代码》规定，以单字母方式标识：

1、专著M ； 报纸N ；期刊J ；专利文献P；汇编G ；古籍O；技术标准S ；

2、学位论文D ；科技报告R；参考工具K ；检索工具W；档案B ；录音带A ；

3、图表Q；唱片L；产品样本X；录相带V；会议录C；中译文T；

4、乐谱I； 电影片Y；手稿H；微缩胶卷U ；幻灯片Z；微缩平片F；其他E。

扩展资料来源：百度百科_参考文献

google之，

这些都是名字的缩写，学位的缩写只有PhD，MD，BD啊,英文文献好像是不标学位的.给你几个示范一下，都是根据国标写的。 作者. 文章名. 刊物类型. 刊物. 年度，期卷号：页码范围 [ ] Nikolaev Yu A, etc. Gas Detonation and its Application in Engineering and Technologies[J]. Combustion, Explosion, and Shock Waves, 2003, 39(4): 382-410 [ ] , P. H. Do. Key Parameters for Controlling of Function Reliability in “None1 Tube” Explosive Transfer System[C], 1999: AIAA99-31211 [ ] Peng Jinhua, Tang Mingjun. One of the Applications of Dust Explosions – Nonel System[J]. Archivum Combustionis, 1989(9): 223-229 [ ] Liu Dabin, Jiang Rongguang, Yang Dong. The Pressure Characteristics of Nonel Tube in Its Detonation Growth Process[J/OL]: 93-96

看看有没有你需要的

英文参考文献格式推荐

在社会的各个领域，大家都写过论文，肯定对各类论文都很熟悉吧，论文是对某些学术问题进行研究的手段。那么你知道一篇好的论文该怎么写吗？以下是我收集整理的英文参考文献格式推荐，欢迎大家分享。

方法/步骤

Journal （期刊）

期刊（Journal）是最常见的参考文献类型，一般需要依次列出以下信息：作者，文章的题目，期刊名称，发表年份，卷号，页码。

提醒：页码也可由DOI、文章编号(Article Number)代替；期刊类型参考文献也可以改成网页类型。

Book（书）

参考文献为书（Book），一般需要列出的信息有：作者，书名，出版社，出版社地点（包括城市和国家），年份，页码

书中的Chapter（章节）

书中的某个章节（Chapter），需要流出的信息有：作者，章节的`题目，书名，编辑，出版社，出版社地点（包括城市和国家），年份，卷号，页码

还未发表的文章（Unpublished Work）

引用了一篇还未发表的文章，你需要列出以下信息：作者，文章题目，期刊名称，阶段。

个人通讯（Personal communication）

个人通讯一般需要你列出作者所在机构和通讯时间。形式一般如图所示。

论文（Thesis）

在参考文献中，也会出现硕士和博士论文的引用，需要给出的信息有：作者，论文题目，论文级别（硕士还是博士），大学名称，大学地址（城市和国家），完成时间

会议（Proceedings）

一个学术会议也可以被引用。一般所需的信息有：作者，会议的名称，会议的地址（城市和国家）会议的时间。