Ext4 Online Defragmentation

Total Page:16

File Type:pdf, Size:1020Kb

Ext4 Online Defragmentation ext4 online defragmentation Takashi Sato NEC Software Tohoku, Ltd. [email protected] Abstract In this paper, an online defragmentation feature for ext4 is proposed, which can solve the fragmentation problem ext4 greatly extends the filesystem size to 1024PB com- on a mounted filesystem. pared to 16TB in ext3, and it is capable of storing many huge files. Previous study has shown that fragmenta- Section 2 describes various features in current Linux tion can cause performance degradation for such large filesystems to reduce fragmentation, and shows how filesystems, and it is important to allocate blocks as con- much fragmentation occurs when multiple processes tiguous as possible to improve I/O performance. writes simultaneously to disk. Section 3 explains the de- sign of the proposed online defragmentation method and In this paper, the design and implementation of an online Section 4 describes its implementation. Section 5 shows defragmentation extension for ext4 is proposed. It is de- the performance benchmark results. Existing work on signed to solve three types of fragmentation, namely sin- defragmentation is shown in Section 6. Section 7 con- gle file fragmentation, relevant file fragmentation, and tains the summary and future work. free space fragmentation. This paper reports its design, implementation, and performance measurement results. 2 Fragmentations in Filesystem 1 Introduction Filesystem on Linux have the following features to re- duce occurrence of fragments when writing a file. When a filesystem has been used for a long time, disk blocks used to store file data are separated into discon- • tiguous areas (fragments). This can be caused by con- Delayed allocation current writes from multiple processes or by the kernel The decision of where to allocate the block on the not being able to find a contiguous area of free blocks disk is delayed until just before when the data is large enough to store the data. stored to disk in order to allocate blocks as con- tiguously as possible (Figure 1). This feature is al- If a file is broken up into many fragments, file read per- ready implemented in XFS and is under discussion formance can suffer greatly, due to the large number of for ext4. disk seeks required to read the data. Ard Biesheuvel has shown the effect of fragmentation on file system perfor- • Block reservation mance [1]. In his paper, file read performance decreases Contiguous blocks are reserved right after the last as the amount of free disk space becomes small because allocated block, in order to use them for successive of fragmentation. This occurs regardless of the filesys- block allocation as shown in Figure 2. This feature tem type being used. is already implemented in ext4. ext3 is currently used as the standard filesystem in Linux, and ext4 is under development within the Linux Although ext4 and XFS already have these features community as the next generation filesystem. ext4 implemented to reduce fragmentation, writing multiple greatly extends the filesystem size to 1024PB compared files in parallel still causes fragmentation and decrease to 16TB in ext3, and it is capable of storing many huge in file read performance. Figure 3 shows the differ- files. Therefore it is important to allocate blocks as con- ence in file read performance between the following two tiguous as possible to improve the I/O performance. cases: • 179 • 180 • ext4 online defragmentation Seconds 1GB file read time(real time) Data 16.5% 22 14.8% degrade 21 degrade write EXT3 XFS 20 19 18 17 16 13 252 2 288 Fragments in 1GB file The environment of the measurement: kernel: 2.6.18-rc4 with Mingming's ext4 patch set CPU: Xeon 3.0GHx This block is freed before the data is Memory: 1GB written to disk, we can write it on the Arch: i386 contiguous blocks Figure 3: The influence of fragments Figure 1: Delayed allocation • Single file fragmentation Data i. Pick up the Single file fragmentation occurs when a single file reserved block is broken into multiple pieces. This decreases the write performance of accessing a single file. • Relevant file fragmentation reserved blocks Relevant file fragmentation occurs when relevant ii. Write to disk files, which are often accessed together by ap- plications are allocated separately on the filesys- tem. This decreases the performance of applica- tions which access many small files. Figure 2: Block reservation • Free space fragmentation Free space fragmentation occurs when the filesys- tem has many small free areas and there is no large • Create the file by writing 32 1GB files sequentially free area consisting of contiguous blocks. This will make the other two types of fragmentation more • Create the file by writing 32 1GB files from 32 likely to occur. threads concurrently Online defragmentation should be able to solve these File read performance decreases about 15% for ext3, three types of fragmentation. and 16.5% for XFS. Currently ext4 does not have any defragmentation fea- 3.2 Single File Fragmentation ture, so fragmentation will not be resolved until the file is removed. Online defragmentation for ext4 is neces- Single file fragmentation could be solved by moving file sary to solve this problem. data to contiguous free blocks as shown in Figure 4. Defragmentation for a single file is done in the following 3 Design of Online Defragmentation steps (Figure 5). 3.1 Types of Fragmentation 1. Create a temporary inode. Fragmentation could be classified into the following 2. Allocate contiguous blocks to temporary file as in three types [2]. Figure 5(a). 2007 Linux Symposium, Volume Two • 181 File ioctl User Kernel Create temporary Move the data to Target Temporary inode and allocate inode inode contiguous blocks contigurous blocks Disk Contiguous free blocks Contiguous blocks (a) Allocate contiguous blocks ioctl Figure 4: Defragment for a single file User Kernel Target page cache Temporary 3. Move file data for each page as described in Figure inode write to inode 5(b). The following sequence of events should be block read from committed to the journal atomically. block (a) Read data from original file to memory page. (b) Swap the blocks between the original inode Contiguous blocks and the temporary inode. (b) Replace data blocks (c) Write data in memory page to new block. Figure 5: Resolving single file fragmentation 3.3 Relevant File Fragmentation Block No = 100 Block No = 100 directory directory Relevant file fragmentation could be solved by moving the files under the specified directory close together with File1 File2 File1 File2 the block containing the directory data as presented in Block No Block No Figure 6. 60000 70000 101 102 Defragmentation for relevant files is done in the follow- Figure 6: Defragment for the relevant files ing steps (Figure 7). 1. The defragmentation program asks the kernel for 5. Repeat steps 2 to 4 for all files under the specified the physical block number of the first block of the directory. specified directory. The kernel retrieves the physi- cal block number of the extent which is pointed by 3.4 Free Space Fragmentation the inode of the directory and returns that value as in Figure 7(a). If the filesystem has insufficient contiguous free blocks, the other files are moved to make sufficient space to allo- 2. For each file under the directory, create a temporary cate contiguous blocks for the target file. Free space de- inode. fragmentation is done in the following steps (Figure 8). 3. The defragmentation command passes the physical block number obtained in step 1 to the kernel. The 1. Find out the block group number to which the tar- kernel searches for the nearest free block after the get file belongs. This could be calculated by using given block number, and allocates that block to the the number of inodes in a group and the inode num- ber as below. temporary inode as described in Figure 7(b). inodeNumber groupNumber = 4. Move file data for each page, by using the same iNodesPerGroup method as for single file defragmentation. 182 • ext4 online defragmentation Specify "0" Return "104" as as the file the physical relative block block number number ioctl() ioctl extent1 extent0 User start=108 start=104 4blocks User 4blocks Kernel inode Kernel extent0 extent1 inode (inode No=201) start = 104 start = 204 5blocks 5blocks exten0 exten1 (a) Get block mapping start=104 start=108 4blos 4blocs ioctl ( goal = 100 ) User (a) Get extens Kernel extent ioctl() original temporary start=104 4blocks inode inode User Allocate a block near goal Kernel Block No = 60000 Block No = 101 inode Register blocks to avoid being used by other files. (b) Specify goal as allocation hint extent start=104 4blocks Figure 7: Resolving relevant files fragmentation reservation window (b) Reserve blocks 2. Get the extent information of all the files belonging ioctl to the target group and choose the combination of User Kernel Search free blocks files to evict for allocating contiguous blocks large Target Temporary from the farthest inode inode group from the enough to hold the target file as in Figure 8(a). target inode. 3. Reserve the chosen blocks so that it will not be used group0 group1 group2 groupN by other processes. This is achieved by the kernel registering the specified blocks to the reservation (c) Move victim file window for each file as presented in Figure 8(b). extent ioctl start=104 14blocks User Kernel Temporary Target inode 4. Move the data in the files chosen in step 2 to other inode block groups. The destination block group could extent start=104 be either specified by the defragmentation com- 14blocks mand or use the block group which is farthest away from the target group as in Figure 8(c).
Recommended publications
  • Fragmentation in Large Object Repositories
    Fragmentation in Large Object Repositories Experience Paper Russell Sears Catharine van Ingen University of California, Berkeley Microsoft Research [email protected] [email protected] ABSTRACT 1. INTRODUCTION Fragmentation leads to unpredictable and degraded application Application data objects continue to increase in size. performance. While these problems have been studied in detail Furthermore, the increasing popularity of web services and other for desktop filesystem workloads, this study examines newer network applications means that systems that once managed static systems such as scalable object stores and multimedia archives of “finished” objects now manage frequently modified repositories. Such systems use a get/put interface to store objects. versions of application data. Rather than updating these objects in In principle, databases and filesystems can support such place, typical archives either store multiple versions of the objects applications efficiently, allowing system designers to focus on (the V of WebDAV stands for “versioning” [25]), or simply do complexity, deployment cost and manageability. wholesale replacement (as in SharePoint Team Services [19]). Similarly, applications such as personal video recorders and Although theoretical work proves that certain storage policies media subscription servers continuously allocate and delete large, behave optimally for some workloads, these policies often behave transient objects. poorly in practice. Most storage benchmarks focus on short-term behavior or do not measure fragmentation. We compare SQL Applications store large objects as some combination of files in Server to NTFS and find that fragmentation dominates the filesystem and as BLOBs (binary large objects) in a database. performance when object sizes exceed 256KB-1MB. NTFS Only folklore is available regarding the tradeoffs.
    [Show full text]
  • ECE 598 – Advanced Operating Systems Lecture 19
    ECE 598 { Advanced Operating Systems Lecture 19 Vince Weaver http://web.eece.maine.edu/~vweaver [email protected] 7 April 2016 Announcements • Homework #7 was due • Homework #8 will be posted 1 Why use FAT over ext2? • FAT simpler, easy to code • FAT supported on all major OSes • ext2 faster, more robust filename and permissions 2 btrfs • B-tree fs (similar to a binary tree, but with pages full of leaves) • overwrite filesystem (overwite on modify) vs CoW • Copy on write. When write to a file, old data not overwritten. Since old data not over-written, crash recovery better Eventually old data garbage collected • Data in extents 3 • Copy-on-write • Forest of trees: { sub-volumes { extent-allocation { checksum tree { chunk device { reloc • On-line defragmentation • On-line volume growth 4 • Built-in RAID • Transparent compression • Snapshots • Checksums on data and meta-data • De-duplication • Cloning { can make an exact snapshot of file, copy-on- write different than link, different inodles but same blocks 5 Embedded • Designed to be small, simple, read-only? • romfs { 32 byte header (magic, size, checksum,name) { Repeating files (pointer to next [0 if none]), info, size, checksum, file name, file data • cramfs 6 ZFS Advanced OS from Sun/Oracle. Similar in idea to btrfs indirect still, not extent based? 7 ReFS Resilient FS, Microsoft's answer to brtfs and zfs 8 Networked File Systems • Allow a centralized file server to export a filesystem to multiple clients. • Provide file level access, not just raw blocks (NBD) • Clustered filesystems also exist, where multiple servers work in conjunction.
    [Show full text]
  • Ext4 File System and Crash Consistency
    1 Ext4 file system and crash consistency Changwoo Min 2 Summary of last lectures • Tools: building, exploring, and debugging Linux kernel • Core kernel infrastructure • Process management & scheduling • Interrupt & interrupt handler • Kernel synchronization • Memory management • Virtual file system • Page cache and page fault 3 Today: ext4 file system and crash consistency • File system in Linux kernel • Design considerations of a file system • History of file system • On-disk structure of Ext4 • File operations • Crash consistency 4 File system in Linux kernel User space application (ex: cp) User-space Syscalls: open, read, write, etc. Kernel-space VFS: Virtual File System Filesystems ext4 FAT32 JFFS2 Block layer Hardware Embedded Hard disk USB drive flash 5 What is a file system fundamentally? int main(int argc, char *argv[]) { int fd; char buffer[4096]; struct stat_buf; DIR *dir; struct dirent *entry; /* 1. Path name -> inode mapping */ fd = open("/home/lkp/hello.c" , O_RDONLY); /* 2. File offset -> disk block address mapping */ pread(fd, buffer, sizeof(buffer), 0); /* 3. File meta data operation */ fstat(fd, &stat_buf); printf("file size = %d\n", stat_buf.st_size); /* 4. Directory operation */ dir = opendir("/home"); entry = readdir(dir); printf("dir = %s\n", entry->d_name); return 0; } 6 Why do we care EXT4 file system? • Most widely-deployed file system • Default file system of major Linux distributions • File system used in Google data center • Default file system of Android kernel • Follows the traditional file system design 7 History of file system design 8 UFS (Unix File System) • The original UNIX file system • Design by Dennis Ritche and Ken Thompson (1974) • The first Linux file system (ext) and Minix FS has a similar layout 9 UFS (Unix File System) • Performance problem of UFS (and the first Linux file system) • Especially, long seek time between an inode and data block 10 FFS (Fast File System) • The file system of BSD UNIX • Designed by Marshall Kirk McKusick, et al.
    [Show full text]
  • Filesystem Considerations for Embedded Devices ELC2015 03/25/15
    Filesystem considerations for embedded devices ELC2015 03/25/15 Tristan Lelong Senior embedded software engineer Filesystem considerations ABSTRACT The goal of this presentation is to answer a question asked by several customers: which filesystem should you use within your embedded design’s eMMC/SDCard? These storage devices use a standard block interface, compatible with traditional filesystems, but constraints are not those of desktop PC environments. EXT2/3/4, BTRFS, F2FS are the first of many solutions which come to mind, but how do they all compare? Typical queries include performance, longevity, tools availability, support, and power loss robustness. This presentation will not dive into implementation details but will instead summarize provided answers with the help of various figures and meaningful test results. 2 TABLE OF CONTENTS 1. Introduction 2. Block devices 3. Available filesystems 4. Performances 5. Tools 6. Reliability 7. Conclusion Filesystem considerations ABOUT THE AUTHOR • Tristan Lelong • Embedded software engineer @ Adeneo Embedded • French, living in the Pacific northwest • Embedded software, free software, and Linux kernel enthusiast. 4 Introduction Filesystem considerations Introduction INTRODUCTION More and more embedded designs rely on smart memory chips rather than bare NAND or NOR. This presentation will start by describing: • Some context to help understand the differences between NAND and MMC • Some typical requirements found in embedded devices designs • Potential filesystems to use on MMC devices 6 Filesystem considerations Introduction INTRODUCTION Focus will then move to block filesystems. How they are supported, what feature do they advertise. To help understand how they compare, we will present some benchmarks and comparisons regarding: • Tools • Reliability • Performances 7 Block devices Filesystem considerations Block devices MMC, EMMC, SD CARD Vocabulary: • MMC: MultiMediaCard is a memory card unveiled in 1997 by SanDisk and Siemens based on NAND flash memory.
    [Show full text]
  • Implementing Nfsv4 in the Enterprise: Planning and Migration Strategies
    Front cover Implementing NFSv4 in the Enterprise: Planning and Migration Strategies Planning and implementation examples for AFS and DFS migrations NFSv3 to NFSv4 migration examples NFSv4 updates in AIX 5L Version 5.3 with 5300-03 Recommended Maintenance Package Gene Curylo Richard Joltes Trishali Nayar Bob Oesterlin Aniket Patel ibm.com/redbooks International Technical Support Organization Implementing NFSv4 in the Enterprise: Planning and Migration Strategies December 2005 SG24-6657-00 Note: Before using this information and the product it supports, read the information in “Notices” on page xi. First Edition (December 2005) This edition applies to Version 5, Release 3, of IBM AIX 5L (product number 5765-G03). © Copyright International Business Machines Corporation 2005. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . xi Trademarks . xii Preface . xiii The team that wrote this redbook. xiv Acknowledgments . xv Become a published author . xvi Comments welcome. xvii Part 1. Introduction . 1 Chapter 1. Introduction. 3 1.1 Overview of enterprise file systems. 4 1.2 The migration landscape today . 5 1.3 Strategic and business context . 6 1.4 Why NFSv4? . 7 1.5 The rest of this book . 8 Chapter 2. Shared file system concepts and history. 11 2.1 Characteristics of enterprise file systems . 12 2.1.1 Replication . 12 2.1.2 Migration . 12 2.1.3 Federated namespace . 13 2.1.4 Caching . 13 2.2 Enterprise file system technologies. 13 2.2.1 Sun Network File System (NFS) . 13 2.2.2 Andrew File System (AFS) .
    [Show full text]
  • External Flash Filesystem for Sensor Nodes with Sparse Resources
    External Flash Filesystem for Sensor Nodes with sparse Resources Stephan Lehmann Stephan Rein Clemens Gühmann stephan.lehmann@tu- stephan.rein@tu- clemens.guehmann@tu- berlin.de berlin.de berlin.de Wavelet Application Group Department of Energy and Automation Technology Chair of Electronic Measurement and Diagnostic Technology Technische Universität Berlin ABSTRACT for using just a few kilobytes of RAM, the source data must This paper describes a free filesystem for external flash mem- be accessible. Another memory intensive task concerns long- ory to be employed with low-complexity sensor nodes. The term sensor logs. system uses a standard secure digital (SD) card that can be easily connected to the serial port interface (SPI) or any A cost effective solution of this memory problem could be general input/output port of the sensor’s processor. The external flash memory. Flash memory is non-volatile and filesystem is evaluated with SD- cards used in SPI mode and therefore power failure safe. Flash memory can be obtained achieves an average random write throughput of about 40 either as raw flash or as standard flash devices such as USB- kByte/sec. For random write access throughputs larger than sticks or SD- cards. Raw flashes are pure flash chips which 400 kByte/sec are achieved. The filesystem allows for stor- do not provide a controller unit for wear levelling- that is, age of large amounts of sensor or program data and can assist a technique for prolonging the service life of the erasable more memory expensive algorithms. It requires 7 kByte of storage media - or garbage collection.
    [Show full text]
  • Total Defrag™ 2009
    Total Defrag™ 2009 User Manual Paragon Total Defrag™ 2009 2 User Manual CONTENTS Introduction ............................................................................................................................. 3 Key Features ............................................................................................................................ 3 Installation ............................................................................................................................... 3 Minimum System Requirements ....................................................................................................................3 Installation Procedure .....................................................................................................................................4 Basic Concepts ......................................................................................................................... 5 A Hard Disk Layout.........................................................................................................................................5 File Fragmentation...........................................................................................................................................6 Defragmentation ..............................................................................................................................................7 Interface Overview.................................................................................................................. 7 General
    [Show full text]
  • System Analysis and Tuning Guide System Analysis and Tuning Guide SUSE Linux Enterprise Server 15 SP1
    SUSE Linux Enterprise Server 15 SP1 System Analysis and Tuning Guide System Analysis and Tuning Guide SUSE Linux Enterprise Server 15 SP1 An administrator's guide for problem detection, resolution and optimization. Find how to inspect and optimize your system by means of monitoring tools and how to eciently manage resources. Also contains an overview of common problems and solutions and of additional help and documentation resources. Publication Date: September 24, 2021 SUSE LLC 1800 South Novell Place Provo, UT 84606 USA https://documentation.suse.com Copyright © 2006– 2021 SUSE LLC and contributors. All rights reserved. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”. For SUSE trademarks, see https://www.suse.com/company/legal/ . All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its aliates. Asterisks (*) denote third-party trademarks. All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its aliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof. Contents About This Guide xii 1 Available Documentation xiii
    [Show full text]
  • Identifying Common Reliability/Stability Problems Caused by File Fragmentation
    WHITE PAPER Identifying Common Reliability/Stability Problems Caused by File Fragmentation Think Faster.™ Visit us at Condusiv.com CT Reliability-Stability WP 12-03-01.indd 1 3/2/12 5:19 PM IDENTIFYING COMMON RELIABILITY/STABILITY PROBLEMS CAUSED BY FILE FRAGMENTATION II Table of Contents INTRODUCTION 1 AN OVERVIEW OF THE PROBLEM 1 RELIABILITY AND STABILITY ISSUES TRACEABLE TO FILE FRAGMENTATION 2 1. Crashes and system hangs 3 2. Slow backup time and aborted backup 5 3. File corruption and data loss 6 4. Boot-up issues 7 5. Errors in programs 7 6. RAM use and cache problems 8 7. Hard drive failures 9 CONTIGUOUS FILES = GREATER UP TIME 10 BIBLIOGRAPHY 11 CT Reliability-Stability WP 12-03-01.indd 2 3/2/12 5:19 PM IDENTIFYING COMMON RELIABILITY/STABILITY PROBLEMS CAUSED BY FILE FRAGMENTATION 1 Introduction Over the years, numerous manufacturers, third party analysts and labs have reported on the effects of disk/file fragmentation on system speed and performance. Defragmentation has also gained recognition for its critical role in addressing issues of system reliability and improved uptime, particularly since Microsoft’s decision to include a defragmentation utility in the Windows 2000 and newer operating systems. Disk fragmentation is In this white paper, we explain some of the most common reliability and downtime phenomena often the “straw that broke associated with fragmentation, and the technical reasons behind them. This includes a discussion the camel’s back” when of each of the most common occurrences documented by our R&D labs, customers (empirical noting issues of stability results presented), as well as others, in recent years.
    [Show full text]
  • Outline of Ext4 File System & Ext4 Online Defragmentation Foresight
    Outline of Ext4 File System & Ext4 Online Defragmentation Foresight LinuxCon Japan/Tokyo 2010 September 28, 2010 Akira Fujita <[email protected]> NEC Software Tohoku, Ltd. Self Introduction ▐ Name: Akira Fujita Japan ▐ Company: NEC Software Tohoku, Ltd. in Sendai, Japan. Sendai ● ▐ Since 2004, I have been working at NEC Software Tohoku developing Linux file system, mainly ext3 and ● ext4 filesystems. Tokyo Currently, I work on the quality evaluation of ext4 for enterprise use, and also develop the ext4 online defragmentation. Page 2 Copyright(C) 2010 NEC Software Tohoku, Ltd. All Rights Reserved. Outline ▐ What is ext4 ▐ Ext4 features ▐ Compatibility ▐ Performance measurement ▐ Recent ext4 topics ▐ What is ext4 online defrag ▐ Relevant file defragmentation ▐ Current status / future plan Page 3 Copyright(C) 2010 NEC Software Tohoku, Ltd. All Rights Reserved. What is ext4 ▐ Ext4 is the successor of ext3 which is developed to solve performance issues and scalability bottleneck on ext3 and also provide backward compatibility with ext3. ▐ Ext4 development began in 2006. Included in stable kernel 2.6.19 as EXPERIMENTAL (ext4dev). Since kernel 2.6.28, ext4 has been released as stable (Renamed from ext4dev to ext4 in kernel 2.6.28). ▐ Maintainers Theodore Ts'o [email protected] , Andreas Dilger [email protected] ▐ ML [email protected] ▐ Ext4 Wiki http://ext4.wiki.kernel.org Page 4 Copyright(C) 2010 NEC Software Tohoku, Ltd. All Rights Reserved. Ext4 features Page 5 Copyright(C) 2010 NEC Software Tohoku, Ltd. All Rights Reserved. Ext4 features Bigger file/filesystem size support. Compared to ext3, ext4 is: 8 times larger in file size, 65536 times(!) larger in filesystem size.
    [Show full text]
  • Defragmenting Hard Disk
    NIELIT GORAKHPUR Course Name: O Level (2nd Sem) Subject: Introduction to ICT Resources Topic: Defragmenting Hard Disk Date: 23-04-2020 Defragmenting Hard Disk After some use, if you feel that your drive has started getting slow, DOS or Windows programs and data files take much more time to load, then most probably this could be due to a fragmentation problem. Disk Fragmentation On a disk drive, any information is stored in clustery. When all the clusters of a file are stored in consecutive sectors, then it is not fragmented but when the clusters which make a file are scattered across the disk, the file or the disk is said to be fragmented. As it takes the read/write head longer to read the file scattered across the disk surface, a fragmented file takes longer to load compared to an un-fragmented file. This can be compared with a real life situation. If your room is not in order, it takes you longer to find something compared to a room where everything is arranged properly. The fragmentation occurs because whenever the operating system wants to write some information on the disk drive, it consults the FAT (File Allocation Table) to find an empty cluster. The FAT keeps a record of used, available and bad (unusable) areas on the disk surface. After finding an empty cluster, the operating system writes to that area and updates the FAT. If the complete file could not be written in one contiguous empty area, then the operating system looks for other areas where the rest of the file can be written.
    [Show full text]
  • NTFS/FAT Disk Defragmentation in RAID and SAN Environments
    Defragmentation Technology | White Paper NTFS/FAT Disk Defragmentation in RAID and SAN Environments A detailed look at how defragmentation really works and how it can deliver significant benefits to RAID or SAN/NAS storage. www.raxco.com 2 There is a common misconception that disk defragmentation is not necessary in RAID or SAN/NAS storage environments. This document explains how disk defragmentation really works and how it can deliver significant benefits to RAID or SAN/NAS storage. The idea that disk defragmentation software is not necessary on RAID or SAN storage arises from a misunderstanding of how disk defragmentation software works and how it interacts with the disk controller software in these environments. At the core of this issue is the common perception that disk defragmentation software directly shuffles around disk clusters. That belief is incorrect. The Windows file systems, FAT and NTFS, “know” absolutely nothing about the configuration of the attached storage. They do not know if a disk is IDE, SCSI, RAID, or SAN. The only thing the file system knows is what kind of partition it is, NTFS or FAT, and how big it is. When a disk is formatted, the file system enumerates the drive into logical disk clusters starting with Logical Cluster Number (LCN) zero up to LCN NNNNNNN, depending on the size of the disk. As file space is allocated and deleted, the file system updates its logical map of the LCN’s. When an application requests a file, the file system queries the Master File Table (for NTFS) and obtains the starting LCN and the run length for the file.
    [Show full text]