Bir dosyanın fiziksel olarak diskte nerede bulunduğunu nasıl öğrenebilirim (blok numaraları)?

10

Bu belirsiz bir soru, biliyorum. Linux kutusundaki bazı disklerin performans testlerini yapmaya çalışıyorum. Aynı testi aynı disk üzerinde çalıştırarak tutarsız sonuçlar elde ediyorum. Diskin hangi kısmına erişildiğine bağlı olarak disklerin farklı performans gösterdiğini biliyorum. Özellikle, diskin dışına yapılan okuma ve yazma işlemleri, neredeyse sabit veri yoğunluğu ve sabit dönme hızı nedeniyle, diskin iç kısmına okuma ve yazma işleminden çok daha yüksek bir verime sahiptir.

Tutarsızlıklarımın bu geometri kaynaklı verimdeki verimden kaynaklanıp kaynaklanamayacağını görmek istiyorum. Mevcut araçları kullanarak, bir dosyanın diskte nereye yerleştirildiğini bulmak mümkün müdür?

Değilse, dosya sistemini atlayarak (ve yok ederek) doğrudan aygıt dosyasının kendisini aramak, okumak ve yazmak için bir şeyler yazabilirim, ancak bundan kaçınmayı umuyorum. Şu anda 3.0 çekirdeğinde ext4 kullanıyorum (Arch Linux, önemliyse), ancak diğer dosya sistemleri için de tekniklerle ilgileniyorum.

— Rick Koshi
kaynak

1

kim demiş dosya bir yerde? Eğer parçalanırlarsa (genellikle yaptıkları gibi) her yerde sonuçlanabilirler.

— Sirex

Kesinlikle. Ama yine de bir yerdeler :-) Ve benim özel durumumda, yeni oluşturulan bir dosya sistemine dosya yazarken, (çoğunlukla) parçalanmamış olmaları muhtemeldir.

— Rick Koshi

Bunu yapamazsın. Alabileceğiniz en iyi, belirli fiziksel konumlara mutlaka karşılık gelmeyen dosyaların LBA blok numaralarıdır (en azından belirleyebileceğiniz bir şekilde değil, sürücüler bu eşlemeyi yayınlamadığından). Başka şeyler de var, örneğin, 3-5 numaralı bloklar ardışık olarak numaralandırılabilir, ancak 4'teki orijinal sektör fiziksel olarak hasar gördüğünden, 4 sürücüde tamamen farklı bir konuma yeniden tahsis edilmiş olabilir. sürücü üreticisi size ayrıntılı adres özellikleri vermek istemiyorsa.

— Jason C

7

Bunun için kullanabilirsiniz debugfs:

debugfs -R "stat ~/myfile" /dev/hda1

Sabit / bölüm sürücüsünü uygun şekilde değiştirin ve sürücünün takılı olmadığından emin olun. Kullanılan tüm blokları içeren bir liste alacaksınız:

BLOCKS:
(0):1643532
TOTAL: 1

— Bart De Vos
kaynak

1

Bu mükemmel, teşekkürler. Yine de sürücünün takılı olmadığından emin olmak için neden söylediğini bilmiyorum. Manuel sayfaya göre, debugfs varsayılan olarak salt okunur modda açılır, bu nedenle bu komut etkin bir dosya sisteminde bile tamamen güvenli olmalıdır. Elbette, sorgulanan dosya o sırada aktif olarak değiştiriliyorsa, şüpheli sonuçlar sağlayabilir, ancak başka hiçbir sorun ortaya çıkmamalıdır. Bir şey kaçırdım mı?

— Rick Koshi

Hayır, haklısın. Bu daha sonra bir 'en iyi uygulama' o zaman bir zorunluluktur. Aktif bir dosya sisteminde yapıyorsanız, dosyalar değişebilir vb.

— Bart De Vos

1

LBA blok numarası, dosyanın fiziksel olarak diskte nerede bulunduğunu söylemez. Fiziksel konuma Tunç çağlarına Bugünlerde dönüşüm Genellikle var konuşma nedeniyle, modern sürücülerin fiziksel geometrisinin karmaşıklığı, genellikle kamera arkası sektör yeniden tahsisler vb mümkün değildir genellikle güvenli bir bahis olduğunu disk tabanlı medya Yerel işletme reklamları düşürmek için sürücünün dışına doğru, ancak bunun nedeni geçmişte CHS adresleme günlerinde tipik olmasıydı. Modern sürücüler artık gerçek CHS geometrisini yayınlamıyor, çünkü yapamıyorlar.

— Jason C

şişman fie sistemleri ne olacak?

— dashesy

10

Sen kullanabilirsiniz FIBMAP ioctl örneklediği gibi, burada , ya kullanılarak hdparm :

/ $ sudo /sbin/hdparm --fibmap /etc/X11/xorg.conf

/etc/X11/xorg.conf:
 filesystem blocksize 4096, begins at LBA 0; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0    1579088    1579095          8

— Francois G
kaynak

Ne yazık ki, stat tarafından çıktı hiçbir şey ihtiyacım olan bilgi. Bayt ve blok cinsinden boyut, inode numarası, izinler ... Bunların hiçbiri, hangi blokların dosyanın verilerini içerdiğini yansıtmaz . Örnek olarak, test dosyalarımın (hepsi aynı boyutta) inode numarası ve erişim / değiştirme süreleri hariç hepsi aynı verileri gösteriyor.

— Rick Koshi

Evet, haklısın, üzgünüm, doğru okumadım. Cevabımı stg'ye daha uygun olarak değiştirdim.

— Francois G

hdparm gerçekten ihtiyacım olanı veriyor ve hata ayıklamalardan biraz daha okunabilir bir formatta. Varsayılan olarak (Arch Linux'ta) yüklü olmadığından, onu bulmak zorundaydım. debugfs e2fsprogs'un bir parçasıdır (bize mkfs ve fsck'i veren paketin aynısı), bu yüzden varsayılan olarak yüklenir.

— Rick Koshi

LBA, dosyanın fiziksel olarak sürücüde nerede bulunduğunu söylemez. LBA'ların gerçek fiziksel haritalaması hakkında bilgi almak mümkün değildir.

— Jason C

Bu şişman olsun:HDIO_GETGEO failed: Inappropriate ioctl for device

— dashesy

5

Bu iş parçacığı size ext4 dosya yerleştirme algoritması hakkında bilgi verebilir.

debugfsbmapistediğiniz veriyi veriyor gibi görünen bir işlevi vardır . Bir dosyanın ardışık bloklarını verebilmeli ve fiziksel blok numaralarını alabilmelisiniz.

— Paweł Brodacki
kaynak

1

Ext4 dosya yerleşimi hakkında iş parçacığına işaretçi için teşekkürler. Bu aydınlatıcıydı. :-)

— Rick Koshi

LBA, dosyanın fiziksel olarak sürücüde nerede bulunduğunu söylemez. LBA'ların gerçek fiziksel haritalaması hakkında bilgi almak mümkün değildir.

— Jason C

2

Soru oldukça eski, ancak bunu Google'da bulanlar için yararlı olabilecek başka bir yanıt var: filefrag(Debian'da paketin içinde e2fsprogs).

# filefrag -eX /usr/bin/aptitude
Filesystem type is: ef53
File size of /usr/bin/aptitude is 4261400 (1041 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..     1fa:    15bd805..   15bd9ff:    1fb:            
   1:      1fb..     3f2:    15c6608..   15c67ff:    1f8:    15bda00:
   2:      3f3..     410:    15c8680..   15c869d:     1e:    15c6800: last,eof
/usr/bin/aptitude: 3 extents found

Burada açıklanan diğer araçlar tarafından desteklenmeyen diğer dosya sistemleri (UDF için kullandım) için de çalışması avantajlıdır.

Çıktıda sunulan ofsetin, ikinci satırda (burada 4096) yazılan blok boyutunun çoğunda olması amaçlanmıştır. Bir dosyada delikler olabileceğinden (dosya sistemi tarafından desteklendiğinde) mantıksal uzaklıklar bitişik olmayabilir.

— Giovanni Mascellani
kaynak