LINUX.ORG.RU

ext2,ext4,fat32 на флешке и фрагментация


0

2

Здравствуте! Занялся вопросом создания универсальной флешки со всевозможными инсталяторами в т.ч. Win7 WinXP. И практически тут же столкнулся с проблемой grub4dos при попытке замапить файл образа на на виртуальное устройство.

File for drive emulation must be in one contiguous disk area
Тут все понятно, файл образа должен состоять из одного фрагмента. Но непонятно почему он фрагментирован, я же его копировал на чистую файловую систему ext2?

Начал разбираться, эксперементирую на JetFlash 2G

Linux alpha-work 3.0.6-gentoo #8 SMP Mon Dec 5 14:21:46 MSK 2011 x86_64 Genuine Intel(R) CPU 2140 @ 1.60GHz GenuineIntel GNU/Linux

Флешка на 2GiB
usb 1-8: New USB device found, idVendor=8564, idProduct=1000
usb 1-8: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 1-8: Product: Mass Storage Device
usb 1-8: Manufacturer: JetFlash
usb 1-8: SerialNumber: 85W2UMLFQWP1RAFF

alpha-work ~ # fdisk -l /dev/sdb
Диск /dev/sdb: 2013 МБ, 2013265920 байт
196 heads, 15 sectors/track, 1337 cylinders, всего 3932160 секторов
Units = секторы of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0438c9e9

Устр-во Загр     Начало       Конец       Блоки   Id  Система
/dev/sdb1            2048     3932159     1965056    b  W95 FAT32

Эксперимент1 Файловая система ext2

alpha-work ~ # mkfs.ext2 /dev/sdb1
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
122880 inodes, 491264 blocks
24563 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=503316480
15 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912

Writing inode tables: done                            
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 29 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
alpha-work ~ # mount /dev/sdb1 /mnt/tmp/
alpha-work ~ # mount | grep sdb1
/dev/sdb1 on /mnt/tmp type ext2 (rw)
alpha-work ~ # rsync -avh --progress /home/alpha/backup/iso/ubuntu-10.04.1-desktop-i386.iso /mnt/tmp/
sending incremental file list
ubuntu-10.04.1-desktop-i386.iso
     718.86M 100%    1.98MB/s    0:05:45 (xfer#1, to-check=0/1)

sent 718.95M bytes  received 31 bytes  2.07M bytes/sec
total size is 718.86M  speedup is 1.00
alpha-work ~ # filefrag -v /mnt/tmp/ubuntu-10.04.1-desktop-i386.iso 
Filesystem type is: ef53
Filesystem cylinder groups is approximately 15
File size of /mnt/tmp/ubuntu-10.04.1-desktop-i386.iso is 718864384 (175504 blocks, blocksize 4096)
 ext logical physical expected length flags
   0       0    18432              12 merged
   1      12    18445    18443   1024 merged
   2    1036    19471    19468   1024 merged
   3    2060    20496    20494   1024 merged
   4    3084    21521    21519   1024 merged
   5    4108    22546    22544   1024 merged
   6    5132    23571    23569   1024 merged
   7    6156    24596    24594   1024 merged
   8    7180    25621    25619   1024 merged
   9    8204    26646    26644   1024 merged
...
...
...
 170  167948   189506   189504   1024 merged
 171  168972   190531   190529   1024 merged
 172  169996   191556   191554   1024 merged
 173  171020   192581   192579   1024 merged
 174  172044   193606   193604   1024 merged
 175  173068   194631   194629   1024 merged
 176  174092   195656   195654    952 merged
 177  175044   197128   196607     72 merged
 178  175116   197201   197199    388 merged,eof
/mnt/tmp/ubuntu-10.04.1-desktop-i386.iso: 179 extents found, perfection would be 1 extent

Тут я что то не понял 179 фрагментов на 700 мб файл? Причем скорость копирования не особо высокая.

Эксперимент2: новейшая ext4 без журнала. журнал отключил в /etc/e2fsck.conf

alpha-work ~ # mke2fs /dev/sdb1 -t ext4flash
mke2fs 1.41.14 (22-Dec-2010)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
122880 inodes, 491264 blocks
24563 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=503316480
15 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912

Writing inode tables: done                            
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 27 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.
alpha-work ~ # mount /dev/sdb1 /mnt/tmp/
alpha-work ~ # mount | grep sdb1
/dev/sdb1 on /mnt/tmp type ext4 (rw)
alpha-work ~ # rsync -avh --progress /home/alpha/backup/iso/ubuntu-10.04.1-desktop-i386.iso /mnt/tmp/
sending incremental file list
ubuntu-10.04.1-desktop-i386.iso
     718.86M 100%   10.03MB/s    0:01:08 (xfer#1, to-check=0/1)

sent 718.95M bytes  received 31 bytes  10.50M bytes/sec
total size is 718.86M  speedup is 1.00
alpha-work ~ # filefrag -v /mnt/tmp/ubuntu-10.04.1-desktop-i386.iso 
Filesystem type is: ef53
File size of /mnt/tmp/ubuntu-10.04.1-desktop-i386.iso is 718864384 (175504 blocks, blocksize 4096)
 ext logical physical expected length flags
   0       0    34816           32768 
   1   32768    67584           30720 
   2   63488   100352    98303  32768 
   3   96256   133120           30720 
   4  126976   165888   163839  14336 
/mnt/tmp/ubuntu-10.04.1-desktop-i386.iso: 3 extents found

Скорость порадовала.. но фрагменты всеравно есть.

Эксперимент3: старая добрая fat32 форматировал под Win7

alpha-work ~ # dosfsck -v  /dev/sdb1
dosfsck 3.0.9 (31 Jan 2010)
dosfsck 3.0.9, 31 Jan 2010, FAT32, LFN
Checking we can access the last sector of the filesystem
Boot sector contents:
System ID "MSDOS5.0"
Media byte 0xf8 (hard disk)
       512 bytes per logical sector
     16384 bytes per cluster
      6276 reserved sectors
First FAT starts at byte 3213312 (sector 6276)
         2 FATs, 32 bit entries
    490496 bytes per FAT (= 958 sectors)
Root directory start at cluster 2 (arbitrary size)
Data area starts at byte 4194304 (sector 8192)
    122560 data clusters (2008023040 bytes)
63 sectors/track, 255 heads
      2048 hidden sectors
   3930112 sectors total
Checking for unused clusters.
Checking free cluster summary.
Free cluster summary uninitialized (should be 122559)
/dev/sdb1: 0 files, 1/122560 clusters
alpha-work ~ # mount /dev/sdb1 /mnt/tmp/
alpha-work ~ # rsync -avh --progress /home/alpha/backup/iso/ubuntu-10.04.1-desktop-i386.iso /mnt/tmp/
sending incremental file list
ubuntu-10.04.1-desktop-i386.iso
     718.86M 100%    1.81MB/s    0:06:19 (xfer#1, to-check=0/1)
rsync: chown "/mnt/tmp/.ubuntu-10.04.1-desktop-i386.iso.UCFXK9" failed: Operation not permitted (1)

sent 718.95M bytes  received 31 bytes  1.89M bytes/sec
total size is 718.86M  speedup is 1.00
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1052) [sender=3.0.8]
alpha-work ~ # filefrag -v /mnt/tmp/ubuntu-10.04.1-desktop-i386.iso 
Filesystem type is: 4d44
File size of /mnt/tmp/ubuntu-10.04.1-desktop-i386.iso is 718864384 (1404032 blocks, blocksize 512)
/mnt/tmp/ubuntu-10.04.1-desktop-i386.iso: 1 extent found

Один фрагмент.

Сразу отмечу что скорость завышенная т.к. юзается буфер записи. Соответственно у меня остались вопросы с которыми я так и не смог разобраться.

1. Как сделать так чтобы на ext2 и ext4 файлы писались в один фрагмент и почему вообще возникает фрагментация? 2. Почему такие разные показатели скорости для ext2 и ext4?

ЗЫ: Остался на fat32



Последнее исправление: mashler (всего исправлений: 2)
Ответ на: комментарий от kombrig

да согласен, на производительность не влияет, но на загрузку образов из под grub4dos влияет

mashler
() автор топика
Ответ на: комментарий от kombrig

А теперь объясни дураку как на flash диске фрагментация влияет на производительность

На запись, например, очень сильно влияет. Даже больше, чем в случае HDD :) Скажем, при записи видео на фотоаппарате, когда класс карточки впритык к требуемому классу идёт, то при записи на нефрагментированную флешку всё пишется идеально, стоит удалить несколько файлов (то есть даже не файлы фрагментированы, а свободное пространство), как запись начинает обламываться.

Объяснять надо, почему, или сам найдёшь? :D

KRoN73 ★★★★★
()
Ответ на: комментарий от kombrig

Размера кластера ФС (обычно 4кбайт), как правило меньше размера блока флешки (128..512кбайт). Стирает флешка информацию только целыми блоками. Писать можно только на стёртый блок.

Был файл. Грохнули. На блоке в 256 кбайт свободна пара секторов. Остальное — занято. Что нужно для записи? Прочитать 256-2*4 кбайт, стереть блок, записать сохранённые 256-2*4 кбайт, записать то, что мы хотим.

Вот тут и начинается жёсткая потеря производительности.

Умные контроллеры современных SSD такие операции проделывают во время ожидания, заранее, прозрачно, в фоне. Но простые флешки или SD-карточки так не умеют.

KRoN73 ★★★★★
()

1. На Ext* через каждые 128мб идут битмапы и группы инодов - фрагментация через которые судя по всему тихо скрывается :)
2. Бекапы суперблоков, твой файл как-бы пересекает их
3. Indirect-блоки в случае ext2/3, на твой файл их как раз и нужно ~170 штук

frame ★★★
()
Ответ на: комментарий от frame

У рейзеров через каждые 128мб битмап, поэтому тоже не подойдут. XFS/JFS тяжелые. NTFS подойдёт, только если MFT/журнал/битмапы перенести в анчало диска. Т.е. единственный приемлемый вариант - чистый раздел FAT16

frame ★★★
()

И практически тут же столкнулся с проблемой grub4dos при попытке замапить файл образа на на виртуальное устройство.
File for drive emulation must be in one contiguous disk area

title The CDROM emulation
map --mem (hd0,0)/fragmented.iso (hd32)
map --hook
chainloader (hd32)
boot

DiMoN ★★★
()
Ответ на: комментарий от DiMoN

title The CDROM emulation
map --mem (hd0,0)/fragmented.iso (hd32)
map --hook
chainloader (hd32)
boot

Вариант, но к сожалению только когда образ может влезть в оперативку.

1. На Ext* через каждые 128мб идут битмапы и группы инодов - фрагментация через которые судя по всему тихо скрывается :)
2. Бекапы суперблоков, твой файл как-бы пересекает их
3. Indirect-блоки в случае ext2/3, на твой файл их как раз и нужно ~170 штук

Спасибо frame, все по полочкам
А вообще конечно стало обидно за ext2 но наверное под flash она не рассчитывалась.

NTFS подойдёт, только если MFT/журнал/битмапы перенести в анчало диска.

Как это сделать? я отчаянно пытался сделать это дефрагментаторами но никак((

В первом приближении по типам ФС я все понял.
Еще у меня остался вопрос по скорости записи. Почему такой большой разброс? Кстати еще наблюдается очень неприятная вещь, при записи на USB Flash большого образа, система встает колом. Т.е. те приложения которым надо считывать или делать запись на диск очень сильно тормозят. После записи файла ситуация нормализуется. Я так понял переполняется буфер записи? Пробвал deadline cfq noop ничего не помогает(( Может надо смотреть в сторону sysctl?

mashler
() автор топика
Ответ на: комментарий от frame

JFS тяжелые

сх*яли? одна из самых легковесных ФС под линуксами.

anonymous
()
Ответ на: комментарий от mashler

Почему такой большой разброс?

В драйвере ext4 довольно агрессивное кеширование, плюс благодаря экстентам нужно писать меньше метаданных (это если свободное место есть, иначе наоборот) по сравнению с ext2/3. Ну и драйвер FAT в линуксе так себе

frame ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.