Question: If I want to `tail` a 25 GB textfile, does the `tail` command read the whole file?

Since a file might be scattered on a disk I imagine it has to, but I do not understand such internals well.

Answer: 
> 
> Since a file might be scattered on a disk I imagine it has to [read the file sequentially], but I do not understand such internals well.
> 
> 
> 

As you now know, `tail` just seeks to the end of the file (with the system call `lseek`), and works backwards. But in the remark quoted above, you're wondering **"how does tail know where on disk to find the end of the file?"** 

The answer is simple: Tail does not know. User-level processes see files as continuous streams, so all `tail` can know is the offset from the start of the file. But in the filesystem, the file's "inode" (directory entry) is associated with a list of numbers denoting the physical location of the file's data blocks. When you read from the file, the kernel / the device driver figures out which part you need, works out its location on disk and fetches it for you. 

That's the kind of thing we have operating systems for: so you don't have to worry about where your file's blocks are scattered.
If `head` or `tail` *appears* to be reading the entire file, a likely reason is that *the file contains few or no newline characters*. I tripped over this a few months ago with a very large (gigabytes) JSON blob that had been serialized with no whitespace whatsoever, not even in strings.

If you have GNU head/tail you can use `-c N` to print the first/last N *bytes* instead of *lines*, but unfortunately this is not a POSIX feature.