Web lists-archives.com

Re: Partition information as text file?




On Wed, Jan 30, 2019 at 09:07:37AM -0600, Richard Owlett wrote:

[...]

> The man pages for fdisk, parted, sfdisk, tune2fs, and dumpe2fs each
> give "device" as a possible parameter. Only the last two balk at it.

This is as if you said that a fillet knife and a nutcracker both
specify "food" as a possible parameter. But expect the cook to
kick you out of the kitchen if you try to crack a nut with the
fillet knife (although you might succeed at it).

As a toolsguy this should be familiar to you.

The last two expect a "device" (which is just a kind of file, you
can do all of that with a bog standard file, everything which can
be seen as a long series of blocks is fair game) _containing_ an
ext2 file system (actually they most probably look first at the
header to check this).

 - (block) device file: (e.g. /dev/sdb)
   a contraption of your operating system making a storage
   device available as a file of sorts, to ease the lives
   of many utilities

 - partition: a part of a block device. Usually (you don't
   _have_ to), a storage device is subdivided into several
   partitions. This subdivision is documented in the
   partition table (which can be the oldskool DOS partition
   table with the well-known limitations of 4 viz. 3+4
   partitions or a more modern GPT or some others living
   out there). Usually this partition table is written as
   a data structure somewhere at the start of the storage
   device (and thus at the first block(s) of the device
   file).

   A partition is usually made available as a device file
   too (e.g. /dev/sdb1)

   A plain regular file can be made available as a device
   via the loopback driver (this is useful for virtual
   machines, but also for experiments -- e.g. I work on
   a file "image" for my Raspi which I can mount and
   look into with my laptop. When I'm happy I just dump
   it to an SD card.

 - file system: the whole machinery needed to organize your
   data whithin a huge unstructured pool of blocks. There
   are many constraints on a file system, like efficient
   space usage, quick allocation of new files, contiguous
   allocation of space (whenever possible) for a file (this
   is most important for mechanical drives), etc.

   There are many different file systems, in response to
   many different requirements and historical roots.

   You typically "put" a file system on a device file (the
   storage behind that is the "backend"), be it a device,
   a partition, a logical volume or a loopback on a
   regular file: the file system code doesn't care, as
   long as it sees a long, boring array of blocks, all
   alike.

Clearer now?

Cheers
-- t

Attachment: signature.asc
Description: Digital signature