Linux за българи: Форуми

Мъчи ме напоследък въпросът,защо като се поддържа толкова добре тази ФС, Линукс не може да се инсталира в-у дял така форматиран.

Това, че на порше можеш да сложиш гуми на трабантче, не обосновава да му смениш цялата ходова част .....

Файловата система се поддържа защото е много стара и стабилна.

Е тези постове, от техническа гледна точка, не отговарят по никакъв начин на въпросът ми.
П.С.
За трабанта и поршето. Ти ми дай на мен едно порше, пък после ще мислим обосновките...

Без да съм пробвал не мисля, че не може да се инсталира Linux на FAT. Само дето според мен наистина е безсмислено. Ще изброя някои основни недостатъци на FAT:
- никаква журналност, т.е. не е fault tolerant.
- бърза фрагментация
- 2ГБ макс файл (и то чак при FAT32)
- 32ГБ макс дял (и то чак при FAT32)
- не поддържа всички файлови атрибути, напр. всички имат макс. права в-у всичко във файловата система

Гореказаното според мен е предостатъчно изобщо да се откаже човек да си инсталира ОС на такава файлова система.

Има zipslack. Това е орязана версия на slackware, която се инсталира върху FAT дял.

Също на времето помня, че slackware си имаше възможност да се инсталира на FAT дял - водеше се umsdos, и имаше някаква хватка - като се инстралираше си правеше едни засукани директории и файлове. Съмнявам се още да се поддържа в slackware така инсталация, но zipslack-а още си е жив така като гледам.


Иначе хората ти дадоха достатъчно причини инсталацията в/у FAT да не е нормална практика.

Всъщност не е проблем да се инсталира линукс върху каквато и да било файлова система - но при повечето случаи ще се наложи да има отделен малък boot-ващ дял с kernel image и специално приготвен initrd (в който да са включени kernel modules подържащи съответната файлова система - в случая FAT, както и loopback device support). Върху FAT файловата система се създава един достатъчно голям файл, с losetup го правиш на loopback device, форматираш го, mount-ваш го (mount -o loop /dev/loopX /mnt/loop). Изкопираш една инсталация отгоре, без /boot, /sys, /proc. Внимателно коригираш /mnt/loop/etc/fstab, за да не стане проблем после (демек слагаш root файловата система да бъде върху /dev/loopX)

В initrd-то просто е необходимо да има един прост linuxrc скрипт, нещо от сорта на следното:

Цитат

mount -t msdos /dev/hdaY /mnt -o uid=0,gid=0,umask=000 losetup /dev/loopX /mnt/bigfile

/dev/hdaY - FAT partition-a
/dev/loopX - loopback device-a
/mnt/bigfile - файлът който си "приготвил" върху FAT дяла

И воала, дефакто линукс се зарежда от каквато искаш файлова система. Не е задължително да е FAT,може да е всякаква, подържана от линукс по възможност read-write.

А иначе това е рядко тъпо решение, защото веднъж имаш кеширането в ядрото на FAT данните, втори път на ext/reiserfs данните в loopback device-a отгоре, отделно файловата система може да не е журнална и да ne пише "дефрагментирано", както е случая с FAT.

Директно върху FAT-а да пльоснеш файловете от инсталацията обаче няма как да стане поради простата причина, че точно FAT е прекалено недъгава файлова система за линукс, не подържа позволения, бавна е, не е устойчива на crash-ване, не подържа "специални" файлове - например char/block devices, sockets, etc, както и не подържа hardlinks (symbolic links се подържат иначе), има ограничения по отношение на максимални големини на файлове и брой файлове в директория и т.н.


Апропо, по горният метод не само че можеш да експериментираш да си сложиш инсталацията върху FAT дял, същото е приложимо и за swap-a. Въпросът е че файдата е почти никаква - единствено заради експеримента може би...

gat3way, много обичаш да словоблудстваш. Това, което описваш не е инсталация на Linux в/у FAT, а инсталация на Linux в/у произволна файлова система, която се намира във файл в/у FAT.

Това е така, но нали целта е да има инсталация върху FAT файлова система, ерго по един или друг начин е постигната

Иначе не бих бил толкова категоричен...vfs/block системата в линукс така е измислена, че да предоставя при желание колкото искаш нива на абстракция. Примерно ако искам мога да форматирам някаква файлова система, в нея да наблъскам loopback device, дори да му създам partition таблица с LVM volume групи/logical volumes, да дефинирам някакъв РАИД между тях, вътре да има нови файлова ситеми, с нови loopdevs и т.н и т.н. Идеята според мен е че файловата система е просто начин на организиране на някакви данни, но тези данни са едни и същи, независимо от начина по който ги организираш. Ако в момента линукс не може да се инсталира хмм "native" върху някаква файлова система, то не означава че по принцип това е невъзможно или пък че е някакъв пропуск - специално в случая с FAT, дори не бих се учудил ако някой вече е пач-нал vfat модула така че да речем да вкарва в един скрит, системен файл, всичките атрибути на файловете и директориите във FAT фс-а. И ако това не е използван и известен  вариант, то предполагам е главно защото би бил ужасно бавен. Представям си как дори ако се налага да изписваш/изчиташ последователни сектори от диска, ще се налагат seek операции, за да провериш дали имаш привилегии за това, прорявайки системния файл дето е на другия край на диска. Другият вариант е да го буферираш и държиш в паметта, което пък ще хаби доволно non-pageable памет.

Както и да е, много офтопик стана, както спомена обичам да словоблудствам Обаче тази логика "подържа добре => трябва да може да буут-ва директно оттам" наистина ми се губи. Това звучи някак си...все едно като знам английски, да го говоря и вкъщи. Не че не може, ама смисълът не ми е ясен.

офф//
@gat3way , кефят ме темите ти   , поучителни са  

Обаче не съм особено прав като се замисля, така че се извинявам. Има огромна разлика между root partition и boot partition. Root partition-a не може да бъде FAT такъв, но може да бъде файл върху FAT, това вече го коментирахме. Въпросът е че в този случай, дефакто boot-ването е от отделен дял, който е форматиран с ext/reiserfs.

Дали е възможно дори boot-ването да става от FAT дяла? (нищо от това по-надолу не съм го правил, така че е само непроверена теория). С grub почти сигурно е невъзможно, тъй като там има някаква рудиментарна подръжка на линукс-ка файлова система, но надали и на FAT. Самият буут-ващ процес на grub е някаква магия според мен, така и не мога да си обясня как са го направили (да наблъскат подръжка на файлова система в рамките на един сектор?!?), но е факт че работи и се ползва. Но в случая няма да свърши работа.

LILO обаче има друг подход. Всеки активен буут-ващ дял започва с boot sector. DOS/win9x ФАТ дяловете също, само дето според документацията на лило, има известна разлика във форматите. Сега като чета, не е особен проблем lilo boot информацията да се запише и върху активен FAT дял, и той да буут-не. Проблемът е че това стане ли, ако този дял трябва да се чете от уиндоус, поради разликата във форматите, уиндоус-а няма да намери полето с указателят към секторите с FAT таблиците, при което целият дял става недостъпен за него. Което само по себе си е забавен казус - дефакто това си е ФАТ файлова система, но достъпна единствено за линукс, хаха.

И предполагам че е възможен и друг вариант - ФАТ дяла да си има уиндоу-ски boot сектор, да се зарежда уин95 (command.com), оттам с loadlin.exe да се буут-ва линукса, разположен във файл върху дяла.

Всичкото това са отново глупави теории и реално погледнато не реализират "native" буут-ване от ФАТ дял, а правят нещата заобиколно. Просто ги споменавам, темата ми стана забавна и взех да съчинявам глупости просто

Според мен е къде по-важно да си оправят собствените файлови системи и начини на работа с тях, отколкото да хвърлят усилия, за да може разни екзотични решения да стават лесни за потребителите. Примерно наскоро имаше разни писания по въпроса защо kernel.org бил бавен и бяха стигнали до извода че getdents()  (функцията която чете directory entries) е реализирана така, че държи lock върху директорията. Всички други процеси, които искат да я прочетат или модифицират, блокират докато не се освободи lock-a. Това съчетано с момента, че ext2/3 може и да пише файловете "дефрагментирано" , но не и съдържанието на директориите, при огромни директории (съответно пръснати из целия диск), до които много процеси се бият за достъп, става огромен проблем. Оказва се че примерно  с xfs това почти не стои като проблем...или пък (хаха) под windows c NTFS.

Така че според мен е по-добре да се изчистват проблеми и да се подобрява производителността на масово използваните неща, вместо да се гонят екзотиките. За NTFS не ми дреме особено, не че хората дето го reverse-ват не правят чудеса, но щом производителят им си крие спецификациите, накрая сам ще си го отнесе

Предполагам, ще е възможно да вдигнеш един рамдиск, да го маунтнеш като /dev и да си mknod-неш вътре квото трябва...макар че честно казано ми се вижда малко идиотско.

Дори да е възможно линукс да използва FAT като native файлова система, това ще повдигне невъзможно много security проблеми, бедна ми е фантазията колко много. Еб*м ти файловата система дето всеки ще може дори shadow файла да модифицира. До голяма степен това може и да се реши ако някой гениален мозък измисли нужните selinux security contexts, "изкомпилира" policies и ги enforce-не. Но трябва да е наистина гений, защото разните частни случаи никой не може да ги предвиди.

Отделно, много неща няма сработят, вкл. доста X-related да речем, mysql "локално, не през tcp sockets" и т.н, защото няма как да създадеш named pipes в тая файлова система и т.н.

Кой знае колко още проблеми ще има...

Прав си, мене ARM нещата са ми доста чужди така или иначе, там изискванията са съвсем други..