webForumDet fria alternativet

Defragmentering av RAID 5 hårddisk.

Databaser & SQL

7 svar · 529 visningar · startad av Mattias Nordin

Medlem sedan dec. 20051 056 inlägg
Frågan#1

Är det någon som sitter på lite kunskap om hur det fungerar med windows filsystem när man använder hårdvaru raid 5.

Filsystemet arbetar ju mot en virutell disk. Hur kan det då komma sig att windows rapporterar disken som totalt fragmenterad?

Jag har tidigare ansett att det är meningslöst att defragmentera en RAID 5 disk i windows. Bör jag tänka om ?

Medlem sedan juni 20014 290 inlägg
#2

Varför skulle inte en Raid5 disk bli fragmenterad?

Varför skulle det vara meningslöst att defragmentera en Raid5 disk?

Raid5 är ju i princip bara ett sätt att slå ihop ett antal diskar till en stor, sedan läggs det en vanligt filsystem ovanpå och självklart kan detta filsystem bli fragmenterat.

Medlem sedan dec. 20051 056 inlägg
#3

Men teori har varit baserad på att defrag applikationen inte har access till hårddisken vid raid 5. Filsystemet tror att det sitter en disk i datorn. Raid 5 lagrar väl samma data på flera diskar så mitt antagande har varit att en vanlig defragmentering inte hjälper då kontroller kortet inte accessar datan fysiskt på samma sätt som filsystemet tror att den existerar.

Men jag forskade vidare lite efter jag skapade tråden...

Tydligen så ska man defragmentera disken i alla fall. Inte för att filerna faktiskt fysiskt lagras defragmenterat utan för att NTFS behöver mindre IO för att accessa en fil när NTFS tror sig vara defragmenterad.

Dålig översättning:

"När en fil är skapad och filsystemet mappar sitt LCN dessa är skickade till disk kontrollen. Controllern mappar LCN till fysiska disk cluster (PCN). När defragmenteringsmjukvaran defragmenterar en fil så rapporterar LCN till disk kontrollern och controllern mappar om filen på disken. Disk defragmenterinsmjukvaran har inte någon aning om var controllern fysikst lagrar filerna... "

Jag skulle anta att reslutatet blir olika grader av bra beroende på hur intelligent disk kontrollern är och hur bra den är på att förstå microsofts defrag API.

Medlem sedan juni 20014 290 inlägg
#4

Raid5 lagrar inte samma data på flera diskar, det är raid1(spegling) du tänker på.

Raid5 sprider ut informationen på flera diskar ( i princip stripe?) plus att i princip 1 disk är inehåller en checksumma så att 1 disk kan gå sönder utan att hela Raid5 systemet går ner. http://sv.wikipedia.org/wiki/RAID#RAID_5

Medlem sedan dec. 20051 056 inlägg
#5

Nej jag tänker på raid 5 men det var dålig formulerat av mig. :(

Notera att jag pratar om hårdvarubaserad raid 5. Nedan tycker jag var intressant läsning...

NTFS/FAT Disk Defragmentation in RAID and SAN Environments 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 intological 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. If the file is logically contiguous, the file system need only do a single logical I/O to access the file. If the file is in more than one logical piece, the file is fragmented. In this case, the file system must locate the starting LCN and run length for every piece of the file. It is not uncommon for “write-active” files to be in thousands of fragments. To access these files the file system must perform thousands of logical I/O’s using both time and resources.

Disk defragmentation software defragments the LCN’s. The Microsoft Defrag API lets defrag software employ different algorithms to invoke their defragmentation strategy. Defragmentation software identifies the LCN’s it wants to move and the target LCN location. The API integrates these requests with the Windows memory manager, the cache manager, and the file system. The file system then updates the pointers to indicate the files new logical location. Access time to read a file that is logically contiguous versus one that is logically fragmented can improve 30-60%. Performing fewer logical I/O’s takes less time, uses less CPU and memory resources, and improves systemperformance.

Everything discussed so far has nothing to do with the physical placement of clusters on a disk. When a file is created and the file system maps its LCN’s, these are then passed to a disk controller. The controller maps the LCN’s to physical disk clusters (PCN’s). When defragmentation software defrags a file, the new location’s LCN will report to the disk

controller and the controller software will remap the file on the disk. The disk defragmentation software has no idea where the disk controller will locate the file on the physical disk.

In the case of RAID or SAN, it is indeed likely that a file that defragmentation software makes logically contiguous will be physically fragmented by the disk controller software. This is OK. The user benefits here in two ways. First, the file system is able to access the file in a single logical I/O taking the minimum elapsed time and using scant CPU and memory. Second, the file is in the best possible place for physical access according to the disk controller’s intelligence.

In 2002, Raxco Software worked with Compaq Computer’s High-End RAID Group to determine what effect defragmentation might have on large RAID configurations. Compaq tested on a machine using the faster processors, the maximum amount of memory, and the fastest disk speeds. The idea was to isolate any performance change to disk I/O. The tests were measured using ZD’s Server Bench and Intel’s IOMeter benchmarking tools. The results showed that defragmentation could improve disk I/O by 50%.

At Microsoft, the Share Point server is a SAN configuration with a 475GB partition with 650GB of compressed data and 20GB changing daily. Microsoft uses Raxco Software’s PerfectDisk®to defragment this environment.

The benefit of disk defragmentation comes not from locating physical clusters on the disk but from reducing file system overhead before any physical disk I/O occurs. Once this concept is understood, the need for defragmentation in large RAID or SAN environments becomes obvious

Medlem sedan juni 20014 290 inlägg
#6

Intressant läsning.

Medlem sedan dec. 20051 056 inlägg
#7

Håller med. Det är nyttigt att grotta ner sig i teknikträsket ibland. Nu ska jag ha lönesamtal. Önska mig lycka till ;)

At the core of this issue is the common perception that disk defragmentation software directly shuffles around disk clusters. That belief is incorrect.

Jag är en av dem som tidigare trott att disk defrag jobbadde direkt mot disken :stud

Medlem sedan juni 20014 290 inlägg
#8

Lycka till! :)

Trodde faktiskt den gjorde det om man har diskarna direkt anslutna (inget raid system), speciellt eftersom många partitioneringsprogram påpekar just att man skall defragmentera innan man splittar en partition i flera partitioner. Dessa kan ju inte dela en partition om data ligger utspridda över hela partitionen.

273 ms totalt · 4 externa anrop · v20260731065814-full.1dc6f849
129 ms — deklarationer (db)
0 ms — hämta statistik (cache)
141 ms — hämta tråd, inlägg och bilagor (db)
126 ms — ändringar (db)