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