1

Why are byte offsets for a pipe/FIFO maintained in the inode rather than the file table, like for regular files?

I read this line at page 113 of The Design of The Unix Operating System (1986) by Maurice Bach.

Maintaining the byte offsets in inode allows convenient FIFO access to the pipe data and differs from the regular files where the offset is maintained in the file table.

  • 2
    Because pipes / FIFOs are not really seekable. – Satō Katsura Feb 22 '17 at 16:04
  • @SatoKatsura I don't understand. Can you Please elaborate. Alose there is another line written after the mentioned lines Processes cannot adjust them via the lseek system call and so random access I/O to pipe is not possible_ – Prakhar Singh Feb 22 '17 at 16:14
  • That book describes the internal of a system from over 30 years ago. While it's certainly an interesting read from an archaeological point of view, you can't assume that modern systems implement things the same way. – Stéphane Chazelas Feb 22 '17 at 16:42
3

Note that that book describes the AT&T Unix system internals as they were 30 years ago. You can't assume things are done the same in modern Unix and unix-like systems.

In any case regardless of how pipes are implemented internally, while for regular files or other seekable files, the byte offset is something that belongs to the open file description (I suppose that's what your book calls a file table entry). That is, two processes opening the same file independently will have each their own offset within the file. One process reading from the file doesn't affect the offset of the other process.

For pipes, all file descriptors of all processes open on a pipe share the same offset. Or in other words the offset belongs to the pipe. So it makes sense to store it in the inode rather than duplicating it in all the open file descriptions.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.