8

I have a 1TB portable hard drive that I use for backups. The entire drive (/dev/sdb) has been formatted as an ext4 filesystem.

I have been reading about the benefits of btrfs for backups (checksums, self-healing, etc) and am considering converting this disk from ext4 to btrfs.

I'm pretty sure I can still resize the disk (e2fsck -f /dev/sdb && resize2fs /dev/sdb 500G && fdisk /dev/sdb, or thereabouts). However, I'm not sure how to "introduce" partitions to a device that didn't have partitions to start with.

Can this be done, and if so, how?

(Note that the filesystems themselves - ext4, btrfs, etc - are pretty much irrelevant - the question is purely about partitioning a device that was initially created without a partition - and doing so without losing the existing filesystem.)

Improve this question
2
  • 2
    This doesn't answer the question, but you can convert an ext4 filesystem to btrfs in-place with btrfs-convert
    – Torin
    Jun 6, 2019 at 10:07
  • in place to lvm conversion: github.com/g2p/blocks and while that still won't add a partition table, makes it easier to subsequently add one after pvmove data relocation
    – frostschutz
    Jun 6, 2019 at 11:02

3 Answers 3

Reset to default
8

Partition tables (at least in MBR or GPT style) live at the start and/or end of disks, so you can introduce them if you can free the required space.

Working with a terabyte disk, I would proceed as follows.

  1. Resize the ext4 file system to 499G (erring on the safe side). This ensures that all the data, file system structure etc. fits within the first 499G’s worth of blocks on the disk. Ideally you should reduce the file system as much as possible, that will reduce the amount of data you need to copy around in subsequent steps.
  2. Copy the blocks to the second half of the disk, using dd or a similar tool.
  3. Partition the disk, creating one partition which is slightly larger than the file system (500G). Use GPT for this; you’ll be overwriting blocks at the start and end of the disk, so the copy of the file system at the start of the disk is now toast.
  4. Copy the raw blocks from the second half of the disk to the newly-created partition, again using dd or something similar. You’ll need to calculate the offsets and sizes based on what you did in step 2, but the target is easy (/dev/sdX1).
  5. Resize the file system again so it occupies all the partition.

With a tool such as ddrescue which can copy in reverse, you could simplify this slightly:

  1. Resize the source file system as much as possible.
  2. Calculate where the first partition would start (without actually creating the partition table).
  3. Move the blocks composing the source file system so that they start where the first partition would start. (This is where you need to start copying from the end.)
  4. Partition the disk.
  5. Resize the file system.

Given the amount of copying involved, it would be easier to back the data up somewhere else and restore it! You could limit the amount of copying by saving the start of the ext4 file system and restoring that followed by the rest of the data, but that requires more careful book-keeping.

Improve this answer
3
  • Sounds logical. I'm half way through a btrfs-convert, so I can't try this, but I've manually stitched partition tables together in the past, so this could work.
    – magnus
    Jun 6, 2019 at 11:25
  • Can the dd utility (or something else) move blocks starting at the end? E.g., move block 8 to 9, 7 to 8, 6 to 7, etc. Doing so might be that only a single dd invocation is required.
    – magnus
    Jun 6, 2019 at 11:26
  • Yes, ddrescue can do this, so I’ve added a “simpler” variant taking advantage of that capability.
    – Stephen Kitt
    Jun 6, 2019 at 11:44
1

I successfully repartitioned a 2 TB drive without data loss. I wanted to perform backups from a GNU/Linux box and a Windows box, so I shrunk the EXT4 partition to 1 TB and created a new 1 TB partition which I formatted as an NTFS file system.

All I needed to do was use the GUI Disks app in Ubuntu. Other distributions should have a similar GUI app for managing partitions. I imagine using BTRFS instead of NTFS would work just as well.

Of course, you should also be able perform the repartitioning from the terminal.

Improve this answer
3
  • 2
    You’re missing the fact that the drive doesn’t have any partitions currently, so a partition-managing GUI application wouldn’t know what to do with it (short of partitioning it and losing anything currently on the drive).
    – Stephen Kitt
    Jun 6, 2019 at 12:53
  • @StephenKitt Would you please explain why it doesn't have a partition? In my understanding, every drive has at least one partition that contains the file system. Am I misunderstanding something?
    – PatOnTheBack
    Jun 6, 2019 at 13:00
  • See Matteo’s answer and the associated comments. File systems can be created directly on a drive, without any partitions; this is the particular issue at hand here.
    – Stephen Kitt
    Jun 6, 2019 at 13:07
-2

I'm confused.

You said the disk is formatted as ext4, so you do have a partition. Maybe fdisk doesn't show it because disk's partition table is gpt and your fdisk doesn't support it. In this case you can use parted

sudo parted -l /dev/sdb

Beside this, you can convert ext4 into btrfs as said in this arch linux guide.

Improve this answer
3
  • 2
    Wrong. Even a regular file on an existing filesystem can be treated as a filesystem. Try this: dd if=/dev/zero of=/tmp/my.ext4 bs=$((1024 * 1024)) count=1 && mkfs.ext4 -F /tmp/my.ext4 && mkdir /tmp/my.ext4.mounted && sudo mount -t ext4 /tmp/my.ext4 /tmp/my.ext4.mounted && ls -l /tmp/my.ext4.mounted. You should see a "lost+found" directory. If a regular file can be a file system, then an entire block device can too.
    – magnus
    Jun 6, 2019 at 10:22
  • I understand this, but it's usually used for (crypto)loop images. Why would you have ever treated a block device like that? I don't see advantages
    – Matteo Fabbroni
    Jun 6, 2019 at 10:27
  • 2
    Unfortunately a lot of people use drives directly without partitioning them at all. And suffer data loss after a wild partition table appeared... helpfully created by some tool or other that thought the drive was empty...
    – frostschutz
    Jun 6, 2019 at 11:05

You must log in to answer this question.

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