To partition or not partition

[Banana]

Recently I've created the filesystem with mk2fs... diretly onto the whole device itself. Like mk2fs.ext4 /dev/sdc, instead of first creating a new partition and the de mk2fs.ext4 /dev/sdc1

Since fdisk does complain with a warning if you use it with this kind of disk (no partition) I've searched around the internet and I'm yet to find a real reason other then, it works better that way and its the default way.

Is this historical or really the better way doing it?
_________________
My personal space
My delta-labs.org snippets do expire

PFL - Portage file list - find which package a file or command belongs to.

[Hu]

Creating a filesystem directly on the device is non-traditional, but mostly works. The biggest argument against it is that some tools assume that an unpartitioned disk is an empty disk, and will happily let you write over a filesystem because they consider that not a real use of the disk. I cannot recall any tools still in common use with that misfeature though.

[pjp]

Related to tools making assumptions, will _you_ always remember that a disk without a partition might not be "empty"? That's easy to dismiss for an in-use drive, but is something to consider.

I think for spinning platters, alignment may have also been a factor in choosing to use partitions, but I could be misremembering.
_________________
Quis separabit? Quo animo?

[NeddySeagoon]

pjp,

A long time ago, when Cylinder/Head/Sector addressing was used there might have been a reason.
However, it didn't really matter if partitions started on a cylinder boundary.

Further back, the partition table was added as a hack, because the FAT filesystem of the day could only map 32MB (yep Mega) and when hard drives reached that limit, the space beyond was lost. The Extended Partition was another hack building on top of the first, so that drives bigger than 128MB could be used.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[pjp]

Thanks, that's why I added the disclaimer. :)

I was thinking where partition boundaries were placed could have impacted fs alignment if not careful. Maybe I was confusing that with the sector size alignment issue.
_________________
Quis separabit? Quo animo?

[Banana]

Thank you for the infos about this topic. So I can and will savely use those disks which do not have any partition in the future.

One thing I can think of: Not having a partiton and you need a partition (only one disk and dual boot) could be a problem? Haveing one, you could easily resize the current one to create a new one on the new space. Not having one, I can only think of a complete reformat of the whole disk and thus deleting all the data.
_________________
My personal space
My delta-labs.org snippets do expire

PFL - Portage file list - find which package a file or command belongs to.

[NeddySeagoon]

Banana,

It's quite safe until your forget and accidentally destroy your filesystem.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[CaptainBlood]

I'd expect it to be a little faster, or is it?

Thks 4 ur attention, interest & support.
_________________
USE="-* ..." in /etc/portage/make.conf here, i.e. a countermeasure to portage implicit braces, belt & diaper paradigm
LT: "I've been doing a passable imitation of the Fontana di Trevi, except my medium is mucus. Sooo much mucus. "

[NeddySeagoon]

CaptainBlood,

It will use a filesystem start of block 0, instead of a partition start.
I would expect it to make no difference to the speed.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[CaptainBlood]

It meant that having a partition table would require additional intermediate computation to map to physical address.
Just a guess on my side...

EDIT: While thinking of it, maybe additional computation, if any required, might be achieved once in the device life scope, then later used as a base for any latter media addressing. In such a case this on time additional computation
should be considered negligible.

Thks 4 ur attention, interest & support.
_________________
USE="-* ..." in /etc/portage/make.conf here, i.e. a countermeasure to portage implicit braces, belt & diaper paradigm
LT: "I've been doing a passable imitation of the Fontana di Trevi, except my medium is mucus. Sooo much mucus. "

[minosi]

My TLDR:
"Do not partition IF you are to place an LVM PV on the device or are in an otherwise controlled setting (VM auto-deploy for scaling etc.)."

All other cases, do partition and go gpt where feasible.
The risk of mis-identifying an unpartitioned device for a blank is real. It is worth it when some real benefit is acquired or the risk is self-mitigated by nature of the system (automated builds).


--------------------------------------------------------------------------------
On why (and when) not to partition a "disk" (aka a storage block device):

Scenario:
A production VM/server running on a virtualized platform under one's control (aka not in some public cloud) like on VMware, KVM, Xen, etc.

Objective:
To be able to increase (and decrease, for those feeling adventurous) filesystem ONLINE, without any downtime. Reliably. Scriptably (!).

Precondition:
Overall complexity of the system topology must not be increased. It shall be decreased if at all possible.
=> "Traditional" LVM-based approaches with "add a PV when space is low" while "working" inside the VG otherwise are a no go as they become un-analyse-able over time.


Problem:
Linux kernel code for partition tables was historically static and while it *can* be updated online recently, one still cannot rely on all the tools and software being updated accordingly.

Solution:
(DB on) FS on (dmcrypt on) LV on VG on PV with a strict 1:1:1:1 mapping.

As in:
(One db containers on) one filesystem (on one dmcrypt device) on one LVM LV on one LVM VG on one LVM PV (ideally slightly bigger then the LV for snapshots) on one /dev/sdx device.

In practice:
Expanding the disk space on a (non-root) filesystem is then easy, usually scripted from the hypervisor via an injected script:
- expand the virtual disk on hypervisor level
- expand the PV from inside guest
- expand the LV from inside guest
- (optional) expand the dmcrypt device from inside guest
- expand the filesystem from inside guest
- (optional) expand the database containter ... etc. etc.

All steps are reliably and safely executable irrespective of system load => primed for automation and full maintainability during prime time on a production box.


The setup presents these advantages:
- skipping the partition remapping saves some CPU cycles /is there though truly negligible/
- skipping the partition table removes a components without function (since in such a setup it trully adds nothing), simplifying performance analysis
- the whole setup is explicitly "dynamic" as LVM and (optional) dmcrypt were build atop device-mapper which was a dynamic stack fron the get-go, this signifficanly reduced risk of some legacy tool/software assuming the device has static characteristics as far as size etc. go
- since there is a PV - with its attendant signature - most software can recognize the device as a non-blank even without a partition table on it


For those familiar with AIX LVM, it is done so in the midrange world since eons ago. (AIX) PVs are directly placed on the devices. No partitions or similar concept needed once LVM PVs are involved.