[OS] Linux администрация homeworks_lecture_02

11. Find the major and minor number of /dev/mptctl and describe what this device is for. ==========================================================================================
In short:
/dev/mptctl @ (major,minor=10,220) - character special device
The “mptctl” kernel module is required to check the RAID status on a Linux server using “mpt-status” tool (the original mpt-status-1.0 tool written by Matt Braithwaite).
It allows one to monitor the health and status of RAID setup.
MegaRAID SAS is the current high-end RAID controllers series by LSI. It is fully hardware RAIDs controllers supporting RAID5, at least, with SAS or SATA interfaces.
mpt-status [ options ]
/dev/mptctl: character special device (major,minor=10,220)
----------------------------------------------------------------- Major and Minor Device Numbers
Devices are divided into sets called major device numbers. Eeach individual device has a minor device number. Major and minor device numbers identify the device to the kernel. The file name of the device is arbitrary and is chosen for convenience and consistency. As of Version 2.6.0 of the kernel, a 32-bit quantity with 12 bits set aside for the major number and 20-bit quantity - for the minor number. The 2.6 kernel can accommodate a vast number of devices, while previous kernel versions were limited to 255 major and 255 minor numbers.
From "ls -l /dev/":
crw--w---- 1 root tty 4, 12 Jul 1 19:27 tty12
"c" - char device; major: 4; minor: 12;
The our case:
10 <--> major number; char device; misc
220 <--> /dev/mptctl Message passing technology (MPT) control
The major number 10 - identifies the device driver of char device and the minor number 220 - identifies a particular device (possibly out of many) that the driver controls.
Character special files or character devices: - through which the system transmits data one character at a time; - often are for stream communication; - usually do not support random access to data; - in most implementations, character devices use unbuffered input and output routines.
Although all devices are listed in the /dev directory, you can create a device anywhere in the file system by using the mknod command:
mknod [-m


Колега сложи едно [OS] пред темата, за да е като за lecture_01 :)

от svenforit (0 точки)

 3. What is the command and its parameters to mount a windows fs in such a way that all files and dirs in it will be owned by user "naso" and group "students"
1. В Windows share-вам папка Cisco. Windows машината е с адрес
2. създаваме група students:
[root@RedHat ~]# groupadd students
3. създаваме потребител naso, който е участващ в група students:
[root@RedHat ~]# useradd -G students  naso
[root@RedHat mnt]# su naso
[naso@RedHat mnt]$ id
uid=500(naso) gid=501(naso) groups=501(naso),500(students) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
4. създаваме папка, в която ще маунтнем windows папката:
[root@RedHat ~]# mkdir /mnt/materials
5. маунтваме със съответните параметри:
[root@RedHat mnt]#  mount -t cifs // /mnt/materials/ -o username=Marty,password=1234,domain=domainname,uid=501,gid=500,file_mode=0777,dir_mode=0777
[root@RedHat mnt]# ll
total 8
drwxrwxrwx. 1 501 students 8192 Jun 21 11:21 materials
[root@RedHat mnt]# cd materials/
[root@RedHat materials]# ll
total 47801
drwxrwxrwx. 0 501 students        0 Mar  5 15:32 ccna1_labs
drwxrwxrwx. 0 501 students        0 Oct 15  2012 ccna2_labs
drwxrwxrwx. 0 501 students        0 Mar  5 15:25 ccna3_labs
drwxrwxrwx. 0 501 students        0 Apr 23 11:49 ccna4_labs
-rwxrwxrwx. 0 501 students  5074173 Mar 10  2011 ccna-portable-command-guide-2nd-edition-self-study-guide.pdf
drwxrwxrwx. 0 501 students        0 Mar  5 15:26 Cisco2
drwxrwxrwx. 0 501 students        0 Nov 14  2012 Cisco3
drwxrwxrwx. 0 501 students        0 Apr 23 11:49 Cisco4
drwxrwxrwx. 0 501 students        0 Jun 27 06:47 CISCO IOS
-rwxrwxrwx. 0 501 students 13929850 Mar  6  2011 Cisco.Press.CCIE.Routing.and.Switching.Exam.Certification.Guide.4th.Edition.Dec.2009.eBook-DDU.pdf
-rwxrwxrwx. 0 501 students 12571941 Oct 11  2012 en_ENetwork_SLM_v4040.pdf
-rwxrwxrwx. 0 501 students   588332 Oct 11  2012 en_ENetwork_SPTM_v4040.pdf
-rwxrwxrwx. 0 501 students    42066 Apr  1 14:11 eswitching-skill-exam-ccna-3.pkt
-rwxrwxrwx. 0 501 students      114 Feb  9 12:45 materials.txt
drwxrwxrwx. 0 501 students        0 Nov 13  2012 practise
-rwxrwxrwx. 0 501 students 18609218 Oct 11  2012 TestKing640-801V107.pdf
drwxrwxrwx. 0 501 students        0 Mar 18  2012 TestKingWorld_Cisco

от mtzvetanov (10 точки)

3. What is the command and its parameters to mount a windows fs in such a way that all files and dirs in it will be owned by user "naso" and group "students". Windows използва основно две файлови системи - NTFS и FAT32. По-долу ще покажем опциите за монтиране на дялове с тези файлови системи към нашата Linux ОС:
1. Създаваме потребител Naso (naso) с uid=1005, член на групи naso и students (gid=1006).
2. Установяваме с кои дялове ще работим за целите на експеримента:
Device Boot Start End Blocks Id System /dev/sda1 * 1 3136 25189888+ 7 HPFS/NTFS ......... /dev/sda6 7638 8338 5630751 b W95 FAT32
3. Създаваме входна точка. В случая ще работим с предварително създадената /media/tmp root@angie-desktop:~# ls -al /media/ ... drwxr-xr-x 2 root root 4096 2011-02-17 19:31 tmp
4. Редактираме /etc/fstab root@angie-desktop:~# nano /etc/fstab добавяме реда: /dev/sda1 /media/tmp ntfs ro,uid=1005,gid=1006,locale=en_US.utf8 0 0
5. Монтираме добавения дял root@angie-desktop:~# mount -a В този случай дискът (sda1) с монтиран само за четене.
6. Проверяваме дали наистина собственикът и групата отговарят на заданието: root@angie-desktop:~# ls -al /media/tmp total 2099472 drwxrwxrwx 1 naso students 20480 2012-03-04 14:09 . drwxr-xr-x 12 root root 4096 2013-07-15 14:03 .. drwxrwxrwx 1 naso students 0 2005-11-30 19:04 Acrobat3 -rwxrwxrwx 1 naso students 9719 1998-05-11 20:01 ANSI.SYS -rwxrwxrwx 1 naso students 559 2005-01-13 13:25 AUTOEXEC.BAT -rwxrwxrwx 1 naso students 543 2002-02-18 22:16 AUTOEXEC.DOS -rwxrwxrwx 1 naso students 438 2000-07-27 11:27 AUTOEXEC.NS0 -rwxrwxrwx 1 naso students 5421 2002-12-17 15:46 banner.jpg -rwxrwxrwx 1 naso students 1297 2003-03-20 13:34 bgmenu.jpg drwxrwxrwx 1 naso students 0 2010-12-30 08:47 BJPrinter .... -rwxrwxrwx 1 naso students 3072 1998-08-05 11:26 template.bbl drwxrwxrwx 1 naso students 4096 2007-07-26 19:42 totalcmd -rwxrwxrwx 1 naso students 16716 2010-09-02 20:51 TREEINFO.WC -rwxrwxrwx 1 naso students 49152 2004-02-26 15:15 VIDEOROM.BIN drwxrwxrwx 1 naso students 110592 2012-03-04 11:47 WINDOWS drwxrwxrwx 1 naso students 4096 2003-12-10 12:42 WORD_DOS
7. Коренспондиращият ред от /etc/mtab e: /dev/sda1 /media/tmp fuseblk ro,nosuid,nodev,allow_other,blksize=4096,default_permissions 0 0
Ако във fstab не използваме ntfs, а ntfs-3g, то дискът може да бъде монтиран с опция rw по-безопасно.
8. Добавяме във fstab следният ред (за диск sda6): /dev/sda1 /media/tmp vfat rw,uid=1005,gid=1006 0 0
9. Монтираме диска root@angie-desktop:/# mount -a
10. Проверка на съдържанието root@angie-desktop:/# ls -al /media/tmp total 28 drwxr-xr-x 4 naso students 16384 1970-01-01 02:00 . drwxr-xr-x 12 root root 4096 2013-07-15 18:22 .. drwxr-xr-x 2 naso students 4096 2012-12-10 15:01 PROBA -rwxr-xr-x 1 naso students 0 2013-07-15 18:21 test.txt drwxr-xr-x 4 naso students 4096 2012-07-24 12:54 .Trash-1000
11. Коренспондиращият ред от /etc/mtab e: /dev/sda6 /media/tmp vfat rw,uid=1005,gid=1006 0 0
12. Тъй като сме използвали rw опцията, сме длъжни да проверим дали наистина може да се пише върху този диск. Установяваме, че root и naso могат да пишат върху диска, докато за останалите потребители това е забранено. angie@angie-desktop:/media/tmp$ touch newtest.txt touch: cannot touch `newtest.txt': Permission denied
Тъй като заданието изисква само да се монтират дяловете със зададените потребител:група, не сме използвали опции за по-детайлна настройка като dmask, fmask и umask.
Литература: Ubuntu Manpage: mount - mount a file system (http://manpages.ubuntu.com/manpages/lucid/man8/mount.8.html) NTFS - Debian Wiki (http://wiki.debian.org/NTFS) How do I correctly mount a NTFS partition in /etc/fstab? (http://askubuntu.com/questions/113733/how-do-i-correctly-mount-a-ntfs-partition-in-etc-fstab)

от angie_bg (214 точки)

4. Write down at least 3 Linux file systems optimized especially for Flash drives(SD cards, USB Drives, SSD disks).
F2FS –> Flash-Friendly File System. An open source Linux file system introduced by Samsung in 2012. http://en.wikipedia.org/wiki/F2FS
JFFS –> Original log structured Linux file system for NOR flash media http://en.wikipedia.org/wiki/JFFS
JFFS2 –> Successor of JFFS, for NAND and NOR flash http://en.wikipedia.org/wiki/JFFS2
LogFS –> Intended to replace JFFS2, better scalability. In early development. http://en.wikipedia.org/wiki/LogFS
UBIFS –> Successor of JFFS2 optimized to utilize non-volatile DRAM http://en.wikipedia.org/wiki/UBIFS
NILFS –> Linux implementation of a log-structured file system NILFS is especially designed for flash memory drives, but does not really perform better than ext4 on benchmarks. http://en.wikipedia.org/wiki/NILFS
Btrfs -> is still considered experimental -> https://wiki.archlinux.org/index.php/Btrfs
EXT4, EXT4 + TRIM: Ext4 is the most common Linux filesystem (well maintained). It provides good performance with SSD and supports the TRIM (and FITRIM) feature to keep good SSD performance over time (this clears unused memory blocks for quick later write access). http://superuser.com/questions/228657/which-linux-filesystem-works-best-with-ssd
Общ източник: http://en.wikipedia.org/wiki/List_of_file_systems

от boyan_BM (147 точки)

Според мен това изброяване на файлови системи щеше да е правилен отговор при условие, че ги няма скобите и там конкретно посочените типове устройства(SD cards, USB Drives, SSD disks).
Ето какво казват на една конференция „Update on filesystems for flash storage” http://elinux.org/images/a/ab/Flash-filesystems.pdf :
We are talking about flash chips, accessed by the Linux kernel as Memory Technology devices. Compact Flash, MMC/SD, Memory Stick cards, together with USB flash drives and Solid State Drives (SSD), are interfaced as block storage, like regular hard disks. Повечето от изброените файлови системи са за устройства от типа MTD(Memory Technology devices) кавито (SD cards, USB Drives, SSD disks) не са.
За устройства (SD cards, USB Drives, SSD disks) от тип block storage специално са разработени F2FS и SquashFS.
Ето още нещо по въпроса от един друг форум http://superuser.com/questions/248078/choice-of-filesystem-for-gnu-linux-on-an-sd-card : Thanks, this is very informative! However, the "big red note" from the UBIFS website says: "One thing people have to understand when dealing with UBIFS is that UBIFS is very different to any traditional file system - it does not work on top of block devices (like hard drives, MMC/SD cards, USB flash drives, SSDs, etc). UBIFS was designed to work on top of raw flash, which has nothing to do with block devices. This is why UBIFS does not work on MMC cards and the like - they look like block devices to the outside world because they implement FTL (Flash Translation Layer) support in hardware." – gspr Feb 20 '11 at 13:21

от GeorgiB (0 точки)

До GeorgiB - Благодаря за хубавото уточнение. Може би е малко подвеждащо и двусмислено понятието optimized especially. Всяка от останалите изброени файлови системи има под някаква форма оптимизация специално за block устройства използващи NAND flash. Аз също се подведох с UBIFS в своето домашно на същата тема.

от ttanev (215 точки)

За това задание не съм много сигурен дали е правилно:
7. Configure agetty for serial console ttyS0 with Systemd.
agetty is an "alternative getty". It takes all of its parameters on the command line, with no use of /etc/gettydefs or any other configuration file. agetty is documented in the manual page agetty(8). Figure 6-6 shows how to invoke agetty for use with a serial console.
-> Figure 6-6. /etc/inittab entry for agetty
co:2345:respawn:/sbin/agetty -h -t 60 ttyS0 9600 vt102
ttyS0 refers to the serial device /dev/ttyS0.
"9600" is the bits per second of the serial link. agetty will support multiple values, using the modem's CONNECT message or the RS-232 Break signal to select between them. Only use one value, as serial consoles only have only one data rate.
"vt102" sets the TERM environment variable to indicate that a VT100 terminal is connecting.
"-h" activates CTS/RTS handshaking.
"-t 60" allows 60 seconds for someone to attempt to log in before the modem is hung up. You should test this feature to ensure that init is not restarting agetty every 60 seconds when the link is idle. Look for a continually changing process identifier for agetty.
agetty uses escape sequences in /etc/issue to insert information. For example, \n.\o \l will appear as remote.example.edu.au ttyS0. When you log out agetty does not appear to lower the Data Terminal Ready signal to force the modme to hang up. If having people automatically disconnected at the end of their login session matters to you then you might consider mgetty instead.
Източник: http://www.faqs.org/docs/Linux-HOWTO/Remote-Serial-Console-HOWTO.html#GETTY

от boyan_BM (147 точки)

4. Write down at least 3 Linux file systems optimized especially for Flash drives(SD cards, USB Drives, SSD disks).
Compact Flash, MMC/SD, Memory Stick cards, together 
with USB flash drives and Solid State Drives (SSD),
are interfaced as block storage, like regular hard disks.
1. F2FS 
F2FS (Flash-Friendly File System) is a flash file system created  at Samsung for the Linux operating system kernel. [2]
The motivation for F2FS was to build a file system that from the start takes into account the characteristics of NAND 
flash memory-based storage devices (such as solid-state disks, eMMC, and SD cards), which have been widely being used 
in computer systems ranging from mobile devices to servers.
Samsung chose a log-structured file system approach, which it adapted to newer forms of storage. 
F2FS also remedies some known issues of the older log structured file systems, such as the snowball effect of 
wandering trees and high cleaning overhead. Because a NAND-based storage device shows different characteristics 
according to its internal geometry or flash memory management scheme (such as the Flash Translation Layer or FTL), 
Samsung also added various parameters not only for configuring on-disk layout, but also for selecting allocation and cleaning algorithms.
2. SquashFS
Filesystem for block storage!?
But read­only! No problem with managing erase blocks and 
wear­leveling. Fine to use with the mtdblock driver.
You can use it for the read­only sections in your filesystem.
Actively maintained. Releases for many kernel versions 
(recent and old).
Flash storage made available only through a block interface.
Hence, no way to access a low level flash interface
and use the Linux filesystems doing wear leveling.
No details about the layer (Flash Translation Layer) they 
use. Details are kept as trade secrets, and may hide poor 
Hence, it is highly recommended to limit the number of 
writes to these devices.
Reducing the number of writes
Mount your filesystems as read­only, or use read­only 
filesystems (SquashFS), whenever possible.
Keep volatile files in RAM (tmpfs)
Use the noatime mount option, to avoid updating the 
filesystem every time you access a file. Or at least, if you 
need to know whether files were read after their last change, 
use the relatime option.
Don't use the sync mount option
(commits writes immediately). No optimizations possible.
You may decide to do without journaled filesystems.
They cause more writes, but are also much more power 
down resistant.

от GeorgiB (0 точки)

Това домашно нарушава две клаузи на избраната тема: 1. Домашното описва само две файлови системи при изрично запитано във въпроса - минимум 3 2. SquashFS не оптимизирана да работи върху Flash devices, за SSD да не говорим.

от hackman (3744 точки)

Describe what is stored in /var/run & /var/lock and how the two dirs are actually used on most Linux distros.
var/run basically is used to store .pid files, which contain the process id of a running program. This is commonly used in services or other programs that need to make their process id's available to other processes.
/var/lock is used to store lock files, which are simply files used to indicate that a certain resource (a database, a file, a device) is in use and should not be accessed by another process. Aptitude, for example, locks its database when a package manager is running.
Both directories contain very small throwaway files that are frequently created or destroyed, so instead of taxing your hard drive with all that activity, they are mounted to a ram drive. A ram drive is just a chunk of your system memory which the OS can treat as if it were a storage device.
Description of /var/run & /var/lock and all structure in your OS you can see by typing:
iskam@bonus:~# man hier
Most Linux distributions follow the FHS ( Filesystem Hierarchy Standard) and declare it their own policy to maintain FHS compliance.This is description from FHS (current version is 2.3, announced on 29 January 2004):
/var/lock : Lock files http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLOCKLOCKFILES
Lock files should be stored within the /var/lock directory structure.
Lock files for devices and other resources shared by multiple applications, such as the serial device lock files that were originally found in either /usr/spool/locks or /usr/spool/uucp, must now be stored in /var/lock. The naming convention which must be used is "LCK.." followed by the base name of the device. For example, to lock /dev/ttyS0 the file "LCK..ttyS0" would be created. Then, anything wishing to use /dev/ttyS0 can read the lock file and act accordingly (all locks in /var/lock should be world-readable).
The format used for the contents of such lock files must be the HDB UUCP lock file format. The HDB format is to store the process identifier (PID) as a ten byte ASCII decimal number, with a trailing newline. For example, if process 1230 holds a lock file, it would contain the eleven characters: space, space, space, space, space, space, one, two, three, zero, and newline.
/var/run : Run-time variable data http://www.pathname.com/fhs/pub/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA
This directory contains system information data describing the system since it was booted. Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process. Programs may have a subdirectory of /var/run; this is encouraged for programs that use more than one run-time file. /var/run should be unwritable for unprivileged users (root or users running daemons); it is a major security problem if any user can write in this directory.Process identifier (PID) files, which were originally placed in /etc, must be placed in /var/run. The naming convention for PID files is

от Fairytale (294 точки)

Здравейте, ето и моето домашно от лекция 02:
4. Write down at least 3 Linux file systems optimized especially for Flash drives(SD cards, USB Drives, SSD disks).
On Wikipedia page for Flash_file_system (https://en.wikipedia.org/wiki/Flash_file_system) are listed several filesystems optimised for flash storage, such as the above mentioned devices.
JFFS - Journaling Flash File System (https://en.wikipedia.org/wiki/JFFS) the first flash specific file system for Linux, quickly superseded by JFFS2 and later YAFFS - Yet Another Flash File System (2002), which was the first optimised for NAND support (as was later JFFS2)
YAFFS2 (https://en.wikipedia.org/wiki/YAFFS#YAFFS2) - uses a more abstract definition of the NAND flash allowing it to be used with a wider variety of flash parts with different geometries, bad block handling rules etc. YAFFS2 later added support for checkpointing, which bypasses normal mount scanning, allowing very fast mount times. Mileage will vary, but mount times of 3 seconds for 2 GB have been reported.
UBIFS - Unsorted Block Image File System (https://en.wikipedia.org/wiki/UBIFS) - first stable release in October 2008 in Linux kernel 2.6.27. Developed by Nokia engineers with the help of Hungarian university of Szeged. The filesystem provides wear leveling and bad block tracking capabilities as it is intended to be used with RAW flash memory media.
LogFS - Linux Log structured and scalable flash file system (https://en.wikipedia.org/wiki/LogFS) - developed with the main purpose to address the scalability issues of JFFS2. Added to mainline Linux kernel in version 2.6.34 with support for use with block devices like SSDs, USB flash drives and memory cards.
F2FS - Flash Friendly File System (https://en.wikipedia.org/wiki/F2FS) - developed at Samsung for Linux operating system kernel, still in unstable state. Introduced first in Linux Kernel 3.8 in February 2013
NILFS - New Implementation of a Log-structured File System (https://en.wikipedia.org/wiki/NILFS) - a log structured file system implementation for Linux, developed by NTT CyberSpace Laboratories, released under GPL, also with read-only support for NetBSD. Supports continuous snapshotting and versioning capabilities with support for restoring deleted contents. Supports also 64 bit data structures, B-tree based file and inode management, Copy-on-write (https://en.wikipedia.org/wiki/Copy-on-write), immediate recovery after system crash, etc. With many to-do list features for upcoming versions.
ZFS - a combined file system and logical volume manager designed by Sun Microsystems. Not optimised especially for flash storage, but intended to be used with different kinds of flash storage for the different layers of disk cache for accelerating random read and random write operations (https://en.wikipedia.org/wiki/ZFS#ZFS_cache:_ARC_.28L1.29.2C_L2ARC.2C_ZIL) With Level 2 Adaptive Replacement Cache (L2ARC) ZFS could cache in fast SSD drives with MLC NAND the most intensively seeked data from the storage and also to speed up deduplication if the entire dedup table is cached in L2ARC. For write operations could be used ZFS Intent Log (ZIL device), which turns synchronous writes into asynchronous. Aside from SLC based SSD drives for ZIL could be used also BBU RAM devices, since with SSD a mirrored setup is recomended.
Other links for additional information: https://en.wikipedia.org/wiki/Comparison_of_file_systems http://www.nilfs.org/en/ https://en.wikipedia.org/wiki/List_of_flash_file_systems#File_systems_optimized_for_flash_memory.2C_solid_state_media
Thanks for reading! :) END

от ttanev (215 точки)

ZFS не е спесифично разработена да работи върху Flash devices. На практика всички jurnal fs-и могат да изместят jurnal-ите си на SSD и ще получат голям speedup, това обаче по никакъв начин не ги прави SSD optimized.

от hackman (3744 точки)

Да, съгласен съм, че по-скоро SSD е оптимизирано за ZFS, отколкото обратното. Въпреки това я споменах, тъй като е една от файловите системи известни именно с гъвкавостта си при използване на flash storage. Поради, което и коментара, че не е специфично оптимизирана за flash storage,

от ttanev (215 точки)

Много ме радва, че хората които са избрали еднаки теми на практика се допълват и така правят отговорът на въпростите още по-добър.

от hackman (3744 точки)

Ето и моя принос, по късно мога да добавя още източнизи по темата,
тъй като намерих повечко :)))))))
източници - https://en.wikipedia.org/wiki/YAFFS - https://en.wikipedia.org/wiki/JFFS2 - https://en.wikipedia.org/wiki/JFFS - https://en.wikipedia.org/wiki/Flash_file_system

Homework 2 --------------------------------------------------------------------------------------- 4. Write down at least 3 Linux file systems optimized especially for Flash drives --------------------------------------------------------------------------------------- --------------------------------------------------------------------------------------- Флаш файловите системи са такива, които са предназначени за съхранение на файлове върху флаш памети от различен тип. Те са широкоразпростанени в момента, поради големия брой мобилни устройства. Тук ще кажа, че block device layer може да емулира дисково устройство, така че дисковата файлова система може да бъде използвана във флаш устройствата, това не е оптимално решение по няколко причини. --------------------------------------------------------------------------------------- 1. Erasing blocks: Флаш блок паметите трябва да бъдат напълно изтрити, преди да бъде записана каквато и да е информация върху тях. Времето необходимо за изтриването им може да бъде значително, като също така се изтриват и незаписаните (неизползвани) блокове памет.
2. Random access или случаен достъп до пеметта: Дисковите файлови системи са оптимизирани да редуцират или още казано да намалят "seek" времето на харддисковете до колкото е възможно. При флаш паметите такова нещо като "seek" време не съществува поради напълно различаната използвана технология.
3. Wear leveling: Флаш паметите позволяват един блок да бъде многократно презаписван, поради тази причина флаш файловите системи са оптимизирани, писането на данни да се осъществява равномерно. --------------------------------------------------------------------------------------- Ще представя три Линукс флаш файлови системи. --------------------------------------------- Те са JFFS/JFFS2/YAFFS ----------------------- JFFS е първата флаш базирана файлова система за Линукс, но бързо е била изместена от JFFS2, първоначално разработена за NOR flash. След това YAFFS е разработена през 2002 г. използваща се особено в NAND flash, като в същото време и JFFS2 е била оптимизирана да подържа NAND flash. ---------------------------------------------------------------------------------------- ---------------------------------------------------------------------------------------- 1. JFFS ------- Journaling Flash File System (JFFS) представлява log-structured file system използвана в NOR флаш памети в Линукс. Флаш паметите, по специално NOR flash трябва предварително да бъдат изтрити преди записването на каквата и да е информация. Процеса на изтриване има няколко ограничения. - Процеса на изтриване се осъществява със значително бавна скорост, от порядъка на 1 до 100 ms за блок, което е около 105 пъти по-бавно от четенето на данни от една и съща област. - Възможно е да се изтрие флаш памет само в големи сегменти ( 64 KiB или повече), докато четенето или записването на информация се осъществява на малки блокове, най-често от порядъка на 512 байта. - Флаш паметите могат да бъдат цялостно изтривани ограничен брой пъти, като броят им е от 103 до 106 пъти преди да започнат да се износват. Тези ограничения се комбинират и се получава голяма асиметрия между процесите четене и запис върху флаш паметите. За разлика от тях магнитните твърди дискове предлагат почти пълна симетрия между четене и запис върху тях, скоростите на четене и запис са почти идентични тоест почти еднакви спрямо една от друга. Възможно е да се пишат и четат малки блокове или сектори от порядъка на 512 байта и на практика няма ограничения от броя на запис и презапис на данни.
- JFFS enforces wear levelling by treating the flash device as a circular log. All changes to files and directories are written to the tail of the log in nodes. In each node, a header containing metadata is written first, followed by file data, if any. Nodes are chained together with offset pointers in the header. Nodes start out as valid and then become obsolete when a newer version of them is created. ------------------------------------------------------------------------------------------------- 2. JFFS2 --------- Journalling Flash File System version 2 или още казано JFFS2 е log структурирана файлова система използвана във флаш паметите. Тя реално е наследникът на JFFS. JFFS2 е включена в ядрото от версия 2.4.10 (2001-09-23), тя също е налична в няколко boot лоудъра като Das U-Boot, Open Firmware, the eCos RTOS и в RedBoot, най-много се използва в OpenWrt. -Сега ще дам и някои от основните и характеристики. Подържа NAND flash устройства. Като това е изисквала сериозна работа върху NAND устройствата имащи последователен I/O interface и те немогат да бъдат memory-mapped за четене. -Hard links. Това не е било възможно при JFFS, поради ограниченията в on-disk формата. -Компресия, като са на разположения четири начина - zlib, rubin, rtime, и lzo. -Има по-добра производителност. В случая JFFS използва паметта като purely circular log. Това от своя страна предизвиква много I/O. garbage collection алгоритъма в JFFS2 на практика прави използването му по този начин излишно. ------------------------------------------------------------------------------------------------- 3. YAFFS --------- Като тази се разделя на още две YAFFS 1 и YAFFS 2. ------------------------------------------------- Yaffs (Yet Another Flash File System) е била направена и написана от Charles Manning за компанията Aleph One. YAFFS 1 представлява първата версия на тази файлова система, която също работи с NAND чипове, които имат 512 байта блокове + 16 byte spare (OOB;Out-Of-Band) areas. На практика несъществува специална процедура за инициализиране на YAFFS файловата система по време на нейното изтриване. Когато в процеса на работата с тази файлова система се открият повредени блокове по някаква причина YAFFS активира така наречената smart media scheme за маркиране на fifth byte of the block's spare area. Тези повредени блокове се маркират като unallocated за в бъдеще и остават практически неизползваеми. За да бъде записана каквато и да е информация YAFFS initially writes a whole page, която описва файлови метаданни , като име, път и прочие. Към новозаписания файл се прикрепя уникален идентификационен номер на дадения обект, тоест всяко пърче информация във файла съдържа този object ID. YAFFS поддържа дървовидна структура в RAM паметта на физическото местоположение на тази данни. Когато една данна вече не е налична, тоест файла е изтрит или презаписан, YAFFS маркира байта в пространството като свободно. Когато се използва YAFFS файловата система върху NAND flash устройство, то трябва да бъде проверен всеки един блок за валидни данни. Когато тази информазия се пресъздаде се получава тази дървовидна структура. YAFFS 2 като концепция е много подобна на YAFFS 1 и използва голяма част от кода и. Основната разлика идва от това, че YAFFS 2 needs to jump through significant hoops to meet the "write once" requirement of modern NAND flash. В YAFFS 2 е добавена поддръжка на checkpointing, което от своя страна пазвалява по-голямо време за mount. ------------------------------------------------------------------------------------------------

от Nikolov89 (20 точки)