3

I was under the impression that a block device is listed under /dev, so for example /dev/xvdf and that file systems live on a partition which is listed with a number behind the block device the partition is on, like /dev/xvdf1 and that all file systems must live on a partition.

I am running CentOS and as part of a course I have to create file systems, partitions and mount file systems. For this course, I have created a file system on device file /dev/xvdf and I have mounted this file system. In addition to that, I have created a partition on /dev/xvdf with the file name of /dev/xvdf1 and created a file system on this partition as well and mounted this file system. This confuses me and I have some questions:

  1. Am I correct that you do not have to create a partition on a block device, but that you can create a file system on a block device directly without a partition?
  2. If so, why would anyone want to do this?
  3. After creating the file system on /dev/xvdf, I created the /dev/xvdf1 partition using fdisk and I allocated the max blocks to this new partition. However, the file system on /dev/xvdf was not removed and still had a file on it. How is this possible if all the blocks on /dev/xvdf have been allocated to the /dev/xvdf1 partition?
Matthias Braun
  • 32,039
  • 22
  • 142
  • 171
Tom
  • 122
  • 2
  • 9
  • Hi, how did you create a filesystem directly on the block device file? Many sd cards on the market come out formatted this way. – Daniele Jan 14 '17 at 10:27
  • @Daniele, it was on a cloud server. And I made the file system via `mkfs -t ext2 /dev/xvdf` – Tom Jan 17 '17 at 06:45

1 Answers1

2

Question #1: you are correct. A file system needs only a contiguous space somewhere. You can also create file system in memory (virtual disk).

Question #2: the possibility of having a partition table is a good thing; but why use it if you don't need to break a disk (or other block device) in several pieces?

About question #3, I think you overlooked something - probably an error raised somewhere and you didn't notice, or some error will raise in future. Even if you have the impression, it can not work; the mounted filesystem thinks to own all the space reserved to it, and similarly fdisk thinks that the blocks it is using "can be used". BTW, what is that "/dev/xvdf"? Is it a real device or whatever?

  • Thank you for the answer. It's a server I get from www.linuxacademy.com and it runs in the Amazon cloud. There linuxacademy attaches the /dev/xvdf device. What if you don't have a partition table, so there is 1 filesystem on the device. And later on you want to create a partition table. How can you do this without losing the files stored on the initial file system? – Tom Dec 28 '16 at 08:54
  • 1
    ...by copying the files somewhere else... :-) – linuxfan says Reinstate Monica Dec 28 '16 at 11:14
  • Alright, however after creating the partition /dev/xvdf1, with the max size for the partition, the files on the /dev/xvdf file system were still there. So it doesnt break, but could these blocks be overwritten without warning by the filesystem on the /dev/xvdf1 partition? – Tom Dec 28 '16 at 12:55
  • 1
    A file system driver wants a contiguous pool of blocks, and reads/writes to them at its will, not necessarily in a predictable way. Data must be coherent, but the driver does not check for coherency - this is duty of fsck(8) command (normally when the filesystem is off-line). fdisk(8) wants a pool of blocks, and writes only to a few of them at the beginning of the pool (it should be only only the first). – linuxfan says Reinstate Monica Dec 28 '16 at 13:40
  • Right, so in my case the /dev/xvdf1 gets all the blocks, the driver can write at will and can possible overwrite the blocks where the /dev/xvdf file system has stored the file, thus making the /dev/xvdf filesystem corrupt? – Tom Dec 28 '16 at 13:42
  • 1
    So, YES - in your situation blocks can be overwritten without warning. Administrative tools want the administrator to know what he is doing. – linuxfan says Reinstate Monica Dec 28 '16 at 13:45
  • 1
    In a way or another, any tool or driver can write to both /dev/xvdf (whole disk) or /dev/xvdf1 (a part of the disk). Those two files in /dev are simply two different ways to see the same blocks. There are also files, there, to see the whole computer memory and still more dangerous things... :-) – linuxfan says Reinstate Monica Dec 28 '16 at 13:50