WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Drive partitioning schemes  (Read 1732 times)

Offline CentralWare

  • Administrator
  • Hero Member
  • *****
  • Posts: 1652
Drive partitioning schemes
« on: February 21, 2015, 12:03:36 AM »
I have been tinkering with an idea for some time based on an accident from a long while ago.
I had a 1TB drive which I was going to flush and repartition.  Being that it was initially formatted/partitioned with Windows I wasn't overly surprised to see random invalid partitions from within fdisk (in many cases they're drives pulled from raid arrays) so, I deleted away in fdisk since I was already in there.  I then went to create a primary and when I went to set a type I noticed the partition table (not written yet) listed it as sda1p1 which threw me for a second before I realized I must have entered fdisk /dev/sda1 instead of /dev/sda.

Thus the notion came to mind of "what would have happened if I divided a single partition into smaller partitions like this?"
/dev/sda1 would then (theoretically) become sda1p1, p2, p3, etc.

I have a personal project I started about 30 minutes ago which is going to utilize network storage (AoE, Network Block or what-not) and I'm going to revamp a pair of SCSI tape drive carousels (20gb uncompressed each if memory serves) so I want to set up a singular drive, probably 1TB SATA-II, and sub-divide into 20gb partitions, totaling roughly 50 partitions on a single hard drive, which if memory serves, is more than 'nix has available for drive identifiers (sdX)  If they were sub-divided in this fashion (say 100gb partitions divided five times each) this should resolve the problem...  "theoretically?"

1: The drives need to be MBR (for compatibility) and I'm not a fan of logical volumes for the intended purpose even if AoE supports it.
2: The operating system would be booting from a separate device, so I'm not worried about boot related issues.

The first question...  does anyone see any caveats setting up sub-division in this fashion?  (SATA is a FIFO serial bottle-neck by design when being used as a shared device, so performance isn't a huge issue unless it was severe.)  The partitions would be formatted EXT4 (up to 4 primary and so many more under extended) for the most part, but I was tinkering with the concept of throwing an intentional NTFS or two into the mix just to see what kind of trouble I could cause.

The second question is regarding SCSI.  I'd be using one or more Adaptec UW SCSI cards to tend to the backups.  I'm unsure whether or not Linux (in general) on a software side even supports tape changers.  Any notes as to what limitations I might run into on either side?

EDIT: Please don't flame by saying things like "Just don't do it!"  Please provide reasoning as it's the heart of understanding.

Thanks and take care!
Over 90% of all computer problems can be traced back to the interface between the keyboard and the chair

Offline core-user

  • Full Member
  • ***
  • Posts: 191
  • Linux since 1999
Re: Drive partitioning schemes
« Reply #1 on: February 21, 2015, 01:41:50 AM »
I accidentally did the same, (created sub partitions), but I didn't try to use them, wasn't sure if they would actually be mountable under Linux. An mbr extended partition is supposed to allow lots of sub partitions which can be mounted, but are identified differently. Likely you could have 50 in an extended without problems.

On another note, BSD can have 16 sub partitions per primary partition, so that would be 48 on one mbr disk. So I'm thinking it is maybe down to the filesystem in use.

Give it a go with a single sub partition & see if you can put a filesystem on it & mount it; & let us all know what happens. :)
AMD, ARM, & Intel.

Offline CentralWare

  • Administrator
  • Hero Member
  • *****
  • Posts: 1652
Re: Drive partitioning schemes
« Reply #2 on: February 21, 2015, 09:23:10 PM »
@core-user: I'll be doing so in the next day or two once I get this machine doing what I need it to.

I was considering "virtual" drives/partitions but that sounded a little too much middle-man in order to tend to communication (between client and server) as well as being a network mounted file system, but...  this should be a fun experiment at the very least! :)

I'll update when I have results.

Ciao!
Over 90% of all computer problems can be traced back to the interface between the keyboard and the chair