1

From man 8 blockdev:

The utility blockdev allows one to call block device ioctls from the command line.

My question is about the following options:

--getfra
Get filesystem readahead in 512-byte sectors.

--getra
Print readahead (in 512-byte sectors).

--setfra sectors
Set filesystem readahead (same as --setra on 2.6 kernels).

--setra sectors
Set readahead (in 512-byte sectors).

I think I know what readahead is in general. What confuses me is "filesystem readahead".

  1. Why are there two separate options: "filesystem readahead" and "readahead"? How do they differ?

  2. Has "filesystem readahead" anything to do with filesystems? What? And if so, then what is the deal with letting blockdev manage this?

    I mean blockdev works with block devices (right?), block devices and filesystems are different levels of abstraction (right?) and we still value "do one thing and do it well" (right?). This is why blockdev dealing with "filesystem something" is surprising to me.

3
  • Note that a mounted filesystem must be on a blockdev. So yes, blcokdev is a lower abstraction than filesystem, but when a real filesystem is mounted, there is a 1:1 bidirectional correspondence with some blockdev.
    – user10489
    Dec 13, 2023 at 5:10
  • @user10489 tmpfs is a filesystem not on a block device (or am I missing something?). And right now I'm using Btrfs that uses two block devices; it's a "real filesystem" without "1:1 bidirectional correspondence". Dec 13, 2023 at 10:06
  • tmpfs is not a "real" filesystem -- it is virtual, and has no block device, there's a lot of those. Good point on btrfs, similarly zfs, probably others. Relation is more complex there. Note that blockdev won't work with those, and those probably also have their own settings for these things.
    – user10489
    Dec 13, 2023 at 13:23

1 Answer 1

1
  1. The two are there for historical reasons; they have been equivalent for twenty years or so IIRC. I can’t remember what the distinction was.

  2. blockdev does one thing (as mentioned in its man page, quoted in the question): it provides access to block device ioctls. Get/set (file system) read-ahead are four block device ioctls, which is why blockdev has switches for them.

3
  • (1) So they are equivalent. The manual could state this clearly. Frankly I interpreted "same as --setra on 2.6" as "--setfra currently is what --setra was on 2.6" and I suspected there was some change after 2.6 that caused renaming the old --setra to --setfra and introducing a new --setra. If I understand correctly, it was probably the other way around: two options converged, two names remained. (2) This shifts the question to "what is the deal with letting block device ioctls manage filesystems?". Irrelevant now, it seems the word "filesystem" here is just a misleading remnant. Dec 13, 2023 at 13:48
  • They may be equivalent at the kernel level but still separate at the user level, so the tool wouldn't know. But that doesn't prevent the documentation from mentioning that. Problem is, a lot of the options in this tool would have documentation burred in kernel api docs or source code.
    – user10489
    Dec 13, 2023 at 14:12
  • In practice the documentation here is (unfortunately) buried in changelogs — I haven’t taken the time yet to dig into that. As you say, Kamil, the different ioctls had meaning some time ago, but the distinction became meaningless. Since blockdev is a very thin shim above the ioctls, and the latter remain, the options remain. The documentation should indeed be updated (I’ll add that to my ever-growing todo list, but if anyone else wants to take care of it feel free!). Dec 13, 2023 at 14:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .