NTFS Dosya Sisteminde File Record Segment (FRS)

Windows işletim sistemlerinde kullanılan NTFS (New Technology File System), yüksek performans, güvenilirlik ve gelişmiş dosya yönetimi yetenekleri sunan bir dosya sistemidir. NTFS’in bu özellikleri sağlayabilmesinin temelinde, dosya ve dizin bilgilerini yöneten Master File Table (MFT) yapısı yer alır.
MFT’nin en küçük yapı taşı ise File Record Segment (FRS) olarak adlandırılır.

Bu makalede, NTFS dosya sistemi içerisinde File Record Segment’in ne olduğu, ne amaçla kullanıldığı ve disk üzerinde nasıl kontrol edildiği ve değiştirilme işlemini ele almış olacağız.

File Record Segment, NTFS dosya sisteminde bir dosya veya dizine ait tüm temel bilgilerin tutulduğu, sabit boyutlu bir veri yapısıdır.
Her dosya ve klasör için en az bir adet FRS bulunur.

Bir FRS içerisinde:

  • Dosya adı
  • Dosya boyutu
  • Zaman damgaları (oluşturma, değiştirme, erişim)
  • Güvenlik tanımlayıcıları (ACL)
  • Dosyanın disk üzerindeki veri bloklarına işaret eden bilgiler

yer alır.

Varsayılan olarak:

  • Bir FRS boyutu 1024 byte (1 KB)’tır
  • Bu değer dosya sistemi oluşturulurken belirlenir
fsutil fsinfo ntfsinfo F:\

Mounted Point Disk için ilgili disk uzantısının belirtilmesi gerekmektedir.

fsutil fsinfo ntfsinfo M:\GOCNET

NTFS dosya sisteminde varsayılan File Record Segment (FRS) boyutu 1024 byte’tır. Eğer disk 1 TB’dan büyükse, bu ayar bazı sorunlara yol açabilir.

Bu durum özellikle çok parçalanmış (fragmented) dosyalarda I/O hatalarına neden olabilir. SQL Server’ın snapshot dosyaları (sparse files) veya çok parçalanmış veri dosyaları buna örnektir.

Bu sorunun sonuçları:
• DBCC CHECKDB çalışırken hata 665 alabilirsiniz:
“The requested operation could not be completed due to a file system limitation”
• Bazı durumlarda veritabanının I/O işlemleri tamamen durabilir ve database offline olabilir.

Neden yukarıdaki belirtilen hatalara sebep olur:
• Windows’ta disk üzerindeki dosyalar aşırı derecede parçalanmışsa.
• Partition, varsayılan (1024 byte) File Record Segment kullanıyorsa.
• NTFS, çok parçalı dosyaları yönetmek için ek kayıtlar oluşturur. Bu kayıtlar aşırı çoğaldığında sorun çıkar.
• SQL Server snapshot’ları (sparse files) veri çok değişiyorsa hızlıca parçalanır.
• DBCC CHECKDB çalışırken SQL Server içeride otomatik snapshot oluşturduğu için bu hata o sırada da meydana gelebilir. İlgili data file’ın olduğu diskte oluşturmaktadır. ‘F:\VERI\GOCNET.mdf_MSSQL_DBCC47’

En iyi çözüm Diskleri /L ile formatlamak

Komut satırından diski formatlarken /L parametresi kullanılırsa:
• File Record Segment boyutu 1024 yerine 4096 byte olur.
• Bu da daha fazla parçalara izin verir ve hata riskini büyük oranda azaltır.

Yani: /L = disk üzerinde daha büyük FRS = daha az 665 hatası

Diskteki FRS boyutunu görmek için:

Sonuçlar içinde “Bytes Per FileRecord Segment” değerine bakılması gerekmektedir.

Hata Olduğunda Ne Yapılır?

1. Eğer hata veritabanı veri dosyasında ise:
• Database offline olabilir.
• Disk defrag yapmak sorunu çözer ama uzun kesinti (downtime) olur.
• Bunu önlemek için:
• Veri dosyalarının başlangıç boyutu büyük verilmeli,
• Autogrowth ayarı kontrollü olmalı.

2. Eğer hata snapshot dosyasında ise:
• Bu dosyalar sparse file olduğu için, parçalanmayı engelleme şansınız yok.
• Snapshot dosyaları, veri değiştikçe parça parça alan ayırır ve çok parçalanır.

Her iki durumda da en sağlam çözüm:
• Diskleri /L ile formatlamak.

Kısaca Özet
• 1024 byte FRS büyük disklerde I/O hatalarına neden olabilir.
• Bu yüzden yeni diskleri /L ile 4096 byte FRS olacak şekilde formatlayın.
• Bu, özellikle SQL Server snapshot ve CHECKDB operasyonlarında 665 hatasını engeller.

Diskinizde Bytes Per FileRecord Segment = 1024 görünüyor. Bu, SQL Server ortamlarında özellikle 1 TB üzeri disklerde 665 gibi I/O hatalarını tetikleyebilen varsayılan fakat riskli ayardır.

Şu anda yapmanız gereken şey, bu diskleri /L parametresiyle yeniden formatlamayı planlamak. Çünkü bu değer çalışan bir diskte değiştirilemez, sadece format sırasında belirlenebilir.

Eğer SQL Server Data / Log dosyaları buradaysa:
• Uzun vadede 665, 1450, I/O hataları, snapshot hataları yaşayabilirsiniz.
• Bu nedenle en doğru çözüm:
Diskleri boşalt → /L ile formatla → verileri geri yükle

Bu işlem diskteki her şeyi siler!

format H: /FS:NTFS /Q /L /V:DataDisk

• /L → FRS’yi 4096 byte yapar (daha güvenli)
• /Q → hızlı format
• /V → volume adı

Reformat mümkün değilse geçici önlemler (ama kesin çözüm değildir)

Eğer diski şu an formatlayamıyorsanız:

✔ Veritabanı dosyalarının auto-growth ayarlarını düzeltin
• Küçük artışlar (1 MB, 10 MB) aşırı fragmentation yaratır.
• Data için 512 MB – 1 GB growth,
• Log için 256–512 MB growth ayarı önerilir.

✔ Snapshot kullanıyorsanız (CHECKDB dahil)
• Snapshot’lar doğası gereği parçalanır → hata riski yüksek
• CHECKDB için bakım saatlerini tercih edin

✔ Disk defrag yapabilirsiniz
• Ancak sadece geçici bir çözümdür

Microsoft’un best-practice’i:

1 TB üzeri tüm SQL veri diskleri 4096-byte FRS ile formatlanmalı (/L).

Bytes Per FileRecord Segment” (FRS) değerini /L ile büyütmek, “Bytes Per Cluster / Allocation Unit Size” değerini değiştirmez. Yani allocation size (cluster size) aynı kalır, yalnızca NTFS’in iç kayıt yapısı büyür.

Disk formatlarken iki farklı şey ayarlanabilir:

1. Allocation Unit Size (Cluster Size)
• Bu, dosyaların disk üzerinde en küçük yer kaplama birimidir.
• Örnek: 4 KB, 8 KB, 16 KB, 64 KB gibi.
• SQL Server için genelde 64 KB önerilir.

2. File Record Segment (FRS) Size
• NTFS’in MFT üzerinde dosyalar için tuttuğu iç kayıt boyutudur.
• Normalde 1024 byte (1 KB) gelir.
• /L parametresi ile 4096 byte (4 KB) olur.
• SQL Server için 4 KB önerilir çünkü parçalanma kaynaklı 665 hatalarını engeller.

Bu iki ayar birbirinden bağımsızdır.

İlgili komut sayesinde disk Allocation Unit Size değeride set etmek istersek aşağıdaki komut kullanılmaktadır.

format H: /FS:NTFS /A:64K /Q /L /V:VERI1

/L bu paremetre 4096 şeklinde ayarlama işlemi yapmaktadır.

Mounted point disk altında ise ilgili diskimiz komutumuz aşağıdaki şekilde formatlanması gerekmektedir.

format M:\GOCNET /FS:NTFS /A:64K /Q /L /V:GOCNET

Yukarıda belirtilen formatlama işlemlerini test olarak tanımlanan disk üzerinde yapılandıralım.

C MD komut satırı yönetici olarak çalıştırılır. Daha sonra yukarıda belirtilen komutlar yazılmaktadır. İlgili komut yazıldıktan sonra Volume ismini teyit etmek için tekrardan yazmamız gerektiğini söylemektedir. Volume belirtildikten sonra Yes ifadesi ile diskimizi /L parametresinin sağlamış olduğu 4096 Byte biçimine formatlamış oluyoruz.

Disk üzerinde tekrardan kontrol işlemi yapıldığında FileRecord Segment değerinin 4096 değerine set edildiğini görmüş oluyoruz.

File Record Segment, NTFS dosya sisteminde dosya ve dizinlere ait tüm temel bilgilerin tutulduğu en küçük ve en önemli yapı taşıdır. Master File Table’ın temelini oluşturan bu yapı, NTFS’in performanslı, güvenilir ve ölçeklenebilir olmasını sağlar.

Not: File record segment size değeri 4096 değerine çekildiğinde yukarıdaki resimde görüldüğü gibi Bytes Per Cluster değeri disk üzerinde default değer neyse o set edilmektedir. Kısacası sql server data dosyalarının üzerinde olduğu disklerde 4096 değerinin set edilmemesi gerekmektedir. Bu işlemin sadece yedek disklerinde yapılması önerilmektedir.

NTFS üzerinde yaşanan pek çok disk ve dosya sistemi probleminin temelinde, doğrudan veya dolaylı olarak FRS yapısı yer alır. Bu nedenle File Record Segment kavramının anlaşılması, sistem yöneticileri ve storage uzmanları için büyük önem taşır.

Başka makalede görüşmek dileğiyle..

De ki: “Şüphesiz benim namazım da, diğer ibadetlerim de, yaşamam da, ölümüm de hepsi Alemlerin Rabbi Allah içindir.” En’am Sûresi 162. Ayet

Author: Yunus YÜCEL

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir