File handling in the Linux kernel

Будет рассмотрен механизм управления файлами в ядре в следующем порядке слоев :

 1 application layer
 2 VFS layer
 3 filesystem layer
 4 generic device layer
 5 device driver layer
 

File handling in the Linux kernel: application layer

Архитектура слоев

Linux kernel в этом смысле не идеален. На то есть причины . Первая : ядро строится многими людьми на протяжении многих лет. Целые куски кода в ядре исчезают бесследно , на их место приходят другие. Вторая : помимо вертикальных слоев , существуют также горизонтальные. Под этим я понимаю подсистемы , которые имеют одинаковый уровень абстракции. Слои , которые рассмотрены в этой статье , не являются общепринятыми по умолчанию в самом ядре.

Будет описан каждый слой и разговор начнется со слоев верхнего уровня. Начнем мы со слоя приложения.

Итак , слои :

• Слой приложения. Это может быть код приложения: C, C++, Java, и т.д.
• Библиотечный слой. Приложения не работают напрямую с ядром . Для этого есть GNU C library (`glibc'). Это касается не только непосредственно приложений , написанных на си , но также и tcl, и java, и т.д.
• VFS . VFS - верхняя , наиболее абстрактная часть ядра управления файлами. VFS включает набор API для поддержки стандартного функционала - open, read, write, и т.д. VFS работает не только с файлами , но также и с pipes, sockets, character devices, и т.д. В основном код VFS лежит в каталоге fs/ ядра.
• Файловая система . Файловая система конвертирует высокоуровневые операции VFS -- reading, writing -- в низко-уровневые операции с дисковыми блоками. Поскольку в большинстве своем файловые системы похожи друг на друга , код VFS по их управлению универсален. Часть кода VFS можно найти в mm/ .
• The generic block device layer. Файловая система не обязательно имеет блочную систему. Например /proc не хранится на диске. VFS не волнует , как реализована файловая система. Модель блочного устройства построена на последовательности блоков данных фиксированного размера. Код лежит в drivers/block. В основном этот код обслуживает базовые функции любых типов блочных устройств , в частности обслуживает буфер и очереди.
• The device driver. Это нижний уровень, наименее абстрактный , напрямую взаимодействующий с драйверами. Он работает с портами IO, memory-mapped IO, DMA, прерываниями. Большинство линуксовых драйверов написано на си . Не все драйвера обслуживают прерывания , их можно разделить на 2 группы , в нижней части находятся например дисковые и SCSI контроллеры.

В данной статье рассматривается пример с приложением , написанном на C, слинкованном с GNU C library. Файловая система - ext2, диск - IDE.

Приложение

char buff[5000];
 int f = open ("/foo/bar", O_RDONLY);
 read (f, &buff, sizeof(buff));
 close (f);
 

Библиотека

int 0x80
 

Приложений может быть много , а дисковый контролер один , и ядро должно предусмотреть его блокировку на тот период , пока он будет обслуживать данный вызов. Такая блокировка происходит на нижних уровнях ядра , и прикладному программисту нет нужды заботиться об этом.

File handling in the Linux kernel: VFS layer

VFS

• независимость от типа файловой системы - ext2, NFS и т.д.
• независимость от железа - IDE , SATA и т.д..

Функция sys_open выглядит примерно так :

int sys_open (const char *name, int flags, int mode)
   {
   int fd = get_unused_fd();
   struct file *f = filp_open(name, flags, mode);
   fd_install(fd, f);
   return fd;
   }
 

sys_open вызывает filp_open() , вызов которой назначается файловому дескриптору. filp_open() определен в open.c, и выглядит примерно так :

struct file *filp_open 
       (const char *name, int flags, int mode)
   {
   struct nameidata nd;
   open_namei (filename, namei_flags, mode, &nd);
   return dentry_open(nd.dentry, nd.mnt, flags);
   }                                                                              
 

Концепция ноды - одна из самых древних в юниксе. Нода - блок данных , который хранит информацию о файле , такую как права доступа , размер , путь. В юниксе различные файловые имена могут указывать на один файл - линки, но каждый файл имеет только одну ноду. Директория - разновидность файла и имеет аналогичную ноду. Нода в завуалированном виде представлена на уровне приложения структурой stat, в которой есть информация о группе , владельце , размере и т.д.
      Поскольку над одним файлом могут трудиться несколько процессов , нужно разграничить права доступа для них на этот файл. В линуксе это реализовано с помощью структуры file. Она включает информацию о файле применительно к ктекущему процессу. Структура file содержит косвенную ссылку на ноду.
      VFS кеширует ноды в памяти , этот кеш управляется с помощью связанного списка , состоящего из структур dentry. Каждая такая dentry включает ссылку на ноду и имя файла.
      Нода - это представление файла , который может быть расшарен; структура file есть представление файла в конкретном процессе , dentry - структура для кеширования нод в памяти .

Вернемся к filp_open(). Она вызывает open_namei(), которая ищет dentry для данного файла. Вычисляется путь относительно рута с помощью слеша . Путь может состоять из нескольких компонентов , и если эти компоненты закешированы в качестве dentry, вычисление пути проходит быстрее. Если файл не был в доступе , его нода наверняка не закеширована. В этом случае она читается слоем файловой системы и кешируется. open_namei() инициализирует структуру nameidata:

struct nameidata 
   {
   struct dentry *dentry;
   struct vfsmount *mnt;
   //...
   }
 

Функция filp_open вычислили нужную dentry, в том числе и нужную ноду , а также структуру vfsmount . open() сам по себе не ссылается на vfsmount. Структура vfsmount хранится в структуре file для будущего использования. filp_open вызывает dentry_open(), которая выглядит так :

struct file *dentry_open
      (struct dentry *dentry, struct vfsmount *mnt, int flags)i
   {
   struct file * f = // get an empty file structure;
 
    f->f_flags = flags;
    // ...populate other file structure elements
 
    // Get the inode for the file
    struct inode = dentry->d_inode;
 
    // Call open() through the inode 
    f->f_op = fops_get(inode->i_fop);
    f->f_op->open(inode, f);
   }
 

Поддержка mount() в VFS

Для того , чтобы получить список поддерживаемых файловых систем , можно набрать :

cat /proc/filesystems
 

int register_filesystem(struct file_system_type *fs)
   {
   struct file_system_type ** p = 
     find_filesystem(fs->name);
   if (*p)
     return -EBUSY;
   else
     { *p = fs; return 0; }
   }
 

struct file_system_type 
   {
   const char *name;
   struct super_block *(*read_super) 
     (struct super_block *, void *, int);
   //...
   }
 

С точки зрения пользователя , для доступа к файловой системе ее нужно примонтировать командой mount. Команда mount вызывает функцию mount(), которая определена в libc-XXX.so. Происходит вызов функции VFS sys_mount(), определенной в fs/namespace.h, sys_mount() проверяет таблицу монтирования :

/*
 sys_mount arguments:
 dev_name - name of the block special file, e.g., /dev/hda1
 dir_name - name of the mount point, e.g., /usr
 fstype - name of the filesystem type, e.g., ext3
 flags - mount flags, e.g., read-only
 data - filesystem-specific data
 */
 long sys_mount
       (char *dev_name, char *dir_name, char *fstype, 
        int flags, char *name, void *data)
   {
   // Get a dentry for the mount point directory 
   struct nameidata nd_dir;
   path_lookup (dir_name, /*...*/, ∓nd_dir);
 
   // Get a dentry from the block special file that
   //  represents the disk hardware (e.g., /dev/hda)
   struct nameidata nd_dev;
   path_lookup (dev_name, /*...*/, ∓nd_dev);
   
   // Get the block device structure which was allocated 
   // when loading the dentry for the block special file.
   // This contains the major and minor device numbers 
   struct block_device *bdev = nd_dev->inode->i_bdev;
 
   // Get these numbers into a packed k_dev_t (see later)
   k_dev_t dev = to_kdev_t(bdev->bd_dev);
 
   // Get the file_system_type struct for the given
   //  filesystem type name
   struct file_system_type *type = get_fs_type(fstype);
 
   struct super_block *sb = // allocate space
   
   // Store the block device information in the sb 
   sb->s_dev = dev;
   // ... populate other generate sb fields
  
   // Ask the filesystem type handler to populate the
   //  rest of the superblock structure
   type->read_super(s, data, flags & MS_VERBOSE)); 
 
   // Now populate a vfsmount structure from the superblock
   struct vfsmount *mnt = // allocate space 
   mnt->mnt_sb = sb;
   //... Initialize other vfsmount elements from sb
 
   // Finally, attach the vfsmount structure to the 
   //  mount point's dentry (in `nd_dir')
   graft_tree (mnt, nd_dir);
   }
 

% mount
 

/dev/hda1 on / type ext2 (rw)
 

      Функция sys_mount() создает пустую структуру superblock , и сохраняет в ней структуру блочного устройства. Хэндлер файловой системы регистрируется с помощью register_filesystem(), прописывая имя файловой системы и адрес функции read_super(). Когда sys_mount() проинициализирует структуру super_block, вызывается функция read_super(). Хэндлер прочтет физический суперблок с диска и проверит его. Будет также проинициализирована структура super_operations, и будет добавлен указатель на поле s_op в структуре super_block . super_operations включает набор указателей на функции базовых файловых операций , таких как создание или удаление файла.
      Когда структура super_block будет проинициализирована , будет заполнена другая структура vfsmount данными из суперблока, после чего vfsmount будет приаттачена к dentry . Это будет сигнал к тому , что данная директория - не просто каталог , а точка монтирования.

Открытие файла

   // Call open() through the inode 
    f->f_op = fops_get(inode->i_fop);
    f->f_op->open(inode, f);
 

File handling in the Linux kernel: filesystem layer

Into the filesystem layer

• The application code calls open() in libc-XXX.so.
• libc-XXX.so traps into the kernel, in a way that is architecture-dependent.
• The kernel's trap handler (which is architecture dependant) calls sys_open.
• sys_open finds the dentry for the file which, we hope, is cached.
• The file's inode structure is retrieved from the dentry.
• The VFS code calls the open function in the inode, which is a pointer to a function provided by the handler for the filesystem type. This handler was installed at boot time, or by loading a kernel module, and made a available by being attached to the mount point during the VFS mount process. The mounted filesystem is represented as a vfsmount structure, which contains a pointer to the filesystem's superblock, which in turn contains a pointer to the block device that handles the physical hardware.

We have seen how the VFS layer calls open through the inode which was created by the filesystem handler for the requested file. As well as open(), a large number of other operations is exposed in the inode structure. Looking at the definition of struct inode (in include/linux/fs.h), we have:

struct inode 
   {
   unsigned long           i_ino;
   umode_t                 i_mode;
   nlink_t                 i_nlink;
   uid_t                   i_uid;
   gid_t                   i_gid;
   // ... many other data fields
 
   struct inode_operations *i_op;
   struct file_operations  *i_fop; 
   }
 

struct file_operations 
   {
   int (*open) (struct inode *, struct file *);
   ssize_t (*read) (struct file *, char *, size_t, loff_t *);
   ssize_t (*write) (struct file *, const char *, size_t, loff_t *);
   int (*release) (struct inode *, struct file *);
   // ... and many more
   }
 

• The application asks the VFS layer to read a file.
• The VFS layer finds the inode and calls the read() function.
• The filesystem handler finds which disk blocks correspond to the part of the file requested by the application via VFS.
• The filesystem handler asks the block device to read those blocks from disk.

The pointers in struct file_operations and struct inode_operations are hooks into the filesytem handler, and we can expect each handler to implement them slightly differently. Or can we? It's worth thinking, for example, about exactly what happens in the filesystem layer when an application opens or reads a file. Consider the `open' operation first. What exactly is meant by `opening' a file at the filesystem level? To the application programmer, `opening' has connotations of checking that file exists, checking that the requested access mode is allowed, creating the file if necessary, and marking it as open. At the filesystem layer, by the time we call open() in struct file_operations() all of this has been done. It was done on the cached dentry for the file, and if the file did not exist, or had the wrong permissions, we would have found out before now. So the open() operation is more-or-less a no-brainer, on most filesystem types. What about the read() operation? This operation will involve doing some real work, won't it? Well, possibly not. If we're lucky, the requested file region will have been read already in the not-too-distant past, and will be in a cache somewhere. If we're very lucky, then it will be available in a cache even if it hasn't been read recently. This is because disk drives work most effectively when they can read in a continuous stream. If we have just read physical block 123, for example, from the disk, there is an excellent chance that the application will need block 124 shortly. So the kernel will try to `read ahead' and load disk blocks into cache before they are actually requested. Similar considerations apply to disk write operations: writes will normally be performed on memory buffers, which will be flushed periodically to the hardware.
      Now, this disk caching, buffering, and read-ahead support is, for the most part filesystem-independent. Of the huge amount of work that goes on when the application reads data from a file, the only part that is file-system specific is the mapping of logical file offsets to physical disk blocks. Everything else is generic. Now, if it is generic, it can be considered part of VFS, along with all the other generic file operations, right? Well, no actually. I would suggest that conceptually the generic filesystem stuff forms a separate architectural layer, sitting between the individual filesystem handlers and the block devices. Whatever the merits of this argument, the Linux kernel is not structured like this. You'll see, in fact, that the code is split between two subsystems: the VFS subsystem (in the fs directory of the kernel source), and the memory management subsystem (in the mm directory). There is a reason for this, but it is rather convoluted, and you may not need to understand it to make sense of the rest of the disk access procedure which I will describe later. But, if you are interested, it's like this.

A digression: memory mapped files

The ext2 filesystem handler

Let's dispose of the open() operation first, as this is trivial (remember that VFS has done all the hard work by the time the filesystem handler is invoked). VFS calls open() in the struct file_operations provided by the filesystem handler. In the ext2 handler, this structure is initialized like this (fs/ext2/file.c):

struct file_operations ext2_file_operations = 
   {
   llseek:         generic_file_llseek,
   read:           generic_file_read,
   write:          generic_file_write,
   ioctl:          ext2_ioctl,
   mmap:           generic_file_mmap,
   open:           generic_file_open,
   release:        ext2_release_file,
   fsync:          ext2_sync_file,
   };
 

int generic_file_open
   (struct inode * inode, struct file * filp)
   {
   if (!(filp->f_flags & O_LARGEFILE) && 
        inode->i_size > MAX_NON_LFS)
     return -EFBIG;
   return 0;
   }
 

The read() operation is more interesting. This function results in a call on generic_file_read(), which is defined in mm/filemap.c (remember, file reads are part of the memory management infrastructure!). The logic is fairly complex, but for our purposes -- talking about file management, not memory management -- can be distilled down to something like this:

/*
 arguments to generic_file_read:
 filp - the file structure from VFS
 buf - buffer to read into
 count - number of bytes to read
 ppos - offset into file at which to read
 */
 ssize_t generic_file_read (struct file * filp, 
     char * buf, size_t count, loff_t *ppos)
   {
   struct address_space *mapping = 
       filp->f_dentry->d_inode->i_mapping;
    
   // Use the inode to convert the file offset and byte
   //  count into logical disk blocks. Work out the number of 
   //  memory pages this corresponds to. Then loop until we
   //  have all the required pages 
   while (more_to_read)
     {
     if (is_page_in_cache)
       {
       // add cached page to buffer
       } 
     else
       {
       struct page *page = page_cache_alloc(mapping);
       // Ask the filesystem handler for the logical page.
       // This operation is non-blocking
       mapping->a_ops->readpage(filp, page);
 
       // Schedule a look-ahead read if possible
       generic_file_readahead(...);
 
       // Wait for request page to be delivered from the IO subsystem
       wait_on_page(page);
 
       // Add page to buffer
       // Mark new page as clean in cache
       }
     } 
   }
 

mapping->a_ops->readpage(filp, page);
 

static int ext2_readpage
       (struct file *file, struct page *page)
   {
   return block_read_full_page(page,ext2_get_block);
   }
 

struct buffer_head 
   {
   struct buffer_head *b_next;     /* Next buffer in list */
   unsigned long b_blocknr;        /* Block number */
   kdev_t b_dev;                   /* Device */
   struct page *page;              /* Memory this block is mapped to */
   void (*b_end_io)(struct buffer_head *bh, int uptodate); 
   // ... and lots more
   }
 

File handling in the Linux kernel: generic device layer

Into the block generic device layer

When the application manipulates a file, the kernel's VFS layer finds the file's dentry structure in memory, and calls the file operations open(), read(), etc., through the file's inode structure. The inode contains pointers into the filesystem handler for the particular filesystem on which the file is located. The handler delegates most of its work to the generic filesystem support code, which is split between the VFS subsystem and the memory management subsystem. The generic VFS code attempts to find the requested blocks in the buffer cache but, if it can't, it calls back into the filesystem handler to determine the physical blocks that correspond to the logical blocks that VFS has asked it to read or write. The filesystem handler populates buffer_head structures containing the block numbers and device numbers, which are then built into a queue of IO requests. The queue of requests is then passed to the generic block device layer.

Device drivers, special files, and modules

Finding the device numbers for a filesystem

path_lookup (dev_name, /*...*/, ∓nd_dev);
 

Registering the driver

devfs_register_blkdev (hwif->major, hwif->name, ide_fops));
 

Request queue management

void blk_queue_make_request
       (request_queue_t *q, make_request_fn *mrf);
 

#define MAJOR = NNN; // Our major number
 
 /*
 my_request_fn() will be called whenever a request is ready 
 to be serviced. Requests are delivered in no particular
 order
 */
 static int my_request_fn 
     (request_queue_t *q, int rw, struct buffer_head *rbh)
   {
   // read or write the buffer specified in rbh
   // ...
   }
 
 // Initialization section
 blk_queue_make_request(BLK_DEFAULT_QUEUE(MAJOR), my_request_fn);
 

If the driver is taking advantage of the kernel's request ordering and coalescing functions, then it register's itself using the function

void blk_init_queue
       (request_queue_t * q, request_fn_proc * rfn);
 

/*
 my_request_fn() will be called whenever a queue of requests 
 is ready to be serviced. Requests are delivered ordered and 
 coalesced
 */
 static int my_request_fn 
     (request_queue_t *q)
   {
   // read or write the queue of buffer specified in *q 
   // ...
   }
 
 // Initialization section
 blk_init_q(BLK_DEFAULT_QUEUE(MAJOR), my_request_fn);
 

Device driver interface

File handling in the Linux kernel: device driver layer

Into the device driver

Interrupts in Linux

      When the interrupt handler is finished, execution resumes at the point at which it was broken off. So, what the driver can do is to tell the hardware to do a particular operation, and then put itself to sleep until the hardware generates an interrupt to say that it's finished. The driver can then finish up the operation and return the data to the caller.
      Most hardware devices that are attached to a computer are capable of generating interrupts. Different architectures support different numbers of interrupts, and have different sharing capabilities. Until recently there was a significant chance that you would have more hardware than you had interrupts for, at least in the PC world. However, Linux now supports `interrupt sharing', at least on compatible hardware. On the laptop PC I am using to write this, the interrupt 9 is shared by the ACPI (power management) system, the USB interfaces (two of them) and the FireWire interface. Interrupt allocations can be found by doing

%cat /proc/interrupts
 

void my_handler (int irq, void *data, 
     struct pt_regs *regs)
   {
   // Handle the interrupt here
   }
 
 int irq = 9; // IRQ number
 int flags = SA_INTERRUPT | SA_SHIRQ; // For example
 char *name = "myhardware";
 char *data = // any data needed by the handler
 request_irq(irq, my_handler, flags, data); 
 

Port IO in Linux

if (!request_region (0x300, 8, "mydriver")) 
   { printk ("Can't allocate ports\n"); }
 

DMA in Linux

The IDE disk driver

// Register the device driver with the kernel.  For
 // first controller, major number is 3.  The name
 // `ide0' will appear in /proc/devices.  ide_fops is a
 // structure that contains pointers to the open,
 // close, and ioctl functions (see previous article).
 devfs_register_blkdev (3, "ide0", ide_fops)
 
 // Initialize the request queue and point it to the
 // request handler.  Note that we aren't using the
 // kernel's default queue this time
 request *q = // create a queue
 blk_dev[3].queue = q; // install it in kernel
 blk_init_queue(q, do_ide_request);
 
 // Register an interrupt handler
 // The real driver works out the IRQ number, but it's
 // usually 14 for the first controller on PCs
 // ide_intr is the handler
 // SA_INTERRUPT means call with interrupts disabled
 request_irq(14, &ide_intr, SA_INTERRUPT, "ide0", 
   /*... some drive-related data */)
 
 // Request the relevant block of IO ports; again 
 // 0x1F0 is common on PCs.
 request_region (0x01F0, 8, "ide0");
 }
 

void ide_intr (int irq, void *data, struct pt_regs *regs)
   {
   // Check that an interrupt is expected
   // Various other checks, and eventually...
 
     handler(); 
   }
 

When requests are delivered to the driver, the method do_ide_request is invoked. This determines the type of the request, and whether the driver is in a position to service the request. If it is not, it puts itself to sleep for a while. If the request can be serviced, then do_ide_request() calls the appropriate function for that type of request. For a read or write request, the function is __do_rw_disk() (in drivers/ide/ide-disk.c). __do_rw_disk() tells the IDE controller which blocks to read, by calculating the drive parameters and outputing them to the control registers. It is a fairly long and complex function, but the part that is important for this discussion looks (rather simplified) looks like this:

 
 int block = // block to read, from the request
 outb(block, IDE_SECTOR_REG);
 outb(block>>=8, IDE_LCYL_REG);
 outb(block>>=8, IDE_HCYL_REG);
 // etc., and eventually set the address of the
 // function that will be invoked on the next
 // interrupt, and schedule the operation on the drive
 if (rq->cmd == READ)
   {
   handler = &read_intr;
   outb(WIN_READ, IDE_COMMAND_REG); // start the read
   }
 

void read_intr(ide_drive_t *drive) 
   {
   // Extract working data from the drive structure
   // passed by the interrupt handler
   struct request *rq = //... request queue
   int nsect = //... number of sectors expected
   char *name = //...name of device
   // Get the buffer from the first request in the
   // queue
   char *to = ide_map_buffer(rq, /*...*/); 
   // in ide-taskfile.c
 
   // And store the data in the buffer
   // This will either be done by reading ports, or it
   // will already have been done by the DMA transfer
   taskfile_input_data(drive, to, nsect * SECTOR_WORDS);
   // in ide-taskfile.c
 
   // Now shuffle the request queue, so the next
   // request becomes the head of the queue
   if (end_that_request_first(rq, 1,  name))
     {
     // All requests done on this queue
     // So reset, and wake up anybody who is listening
      end_that_request_last (rq); 
     }
   }
 

int end_that_request_first(structure request *req, 
     int uptdate, char *name)  
   { 
   struct buffer_head *bh = req->bh; 
   bh->b_end_io (bh, uptodate);
   // Adjust buffer to make next request current  
   if (/* all requests done */) return 1; 
   return 0; 
   }
 

Summary

Оставьте свой комментарий !
Ваше имя: Комментарий: Оба поля являются обязательными  Автор   Комментарий к данной статье