Backing Up HDD to External Drive over USB 2.0

Technical issues/questions of an intermediate or advanced nature.
Bogomips
Full of knowledge
Full of knowledge
Posts: 2562
Joined: 25 Jun 2014, 15:21
Distribution: 3.2.2 Cinnamon & KDE5
Location: London

Backing Up HDD to External Drive over USB 2.0

Post#1 by Bogomips » 15 Jan 2017, 22:45

Twinge of anxiety on reading instruction booklet, that external drive compatible with XP/Vista/Win 7/8/8.1 and Mac OS 10.x. Linux does not get a look in, and curiously enough neither does Win$oze 10! However 4.9.0 and even 4.4 (Mint Sarah) seem up to the task:

Code: Select all

guest@porteus:~$ sudo /sbin/fdisk -l /dev/sdb
Disk /dev/sdb: 2.7 TiB, 3000592965632 bytes, 732566642 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 32768 bytes / 268431360 bytes
Disklabel type: dos
Disk identifier: 0x6020b5f5

Device     Boot Start       End   Sectors  Size Id Type
/dev/sdb1         256 732563999 732563744  2.7T  c W95 FAT32 (LBA)
 
Neither KDE Partition Manger nor Gparted seem able to deal with this monster, when it comes to resizing sdb1. Gparted resize dialog doesn't do anything, while KDE's errors out in the resize operation:
Image
It looks like will have to bite the bullet and overwrite the partition table. As it is, did not wish to move resized partition, but program insists on doing it. :( Unless of course someone has some experience in this area?
Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB

User avatar
Ed_P
Contributor
Contributor
Posts: 3216
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 3.2.2 64-bit ISO
Location: Western NY, USA

Re: Backing Up HDD to External Drive over USB 2.0

Post#2 by Ed_P » 16 Jan 2017, 05:59

Why do you want to partition it? Why can't you just create folders on it for your videos?

As for no mention of Win 10 in the documentation to me would indicate the drive/manual were packaged 3 or more yrs ago.
Bogomips wrote: but program insists on doing it.
What program?
Ed

tome
Contributor
Contributor
Posts: 562
Joined: 26 Jun 2013, 14:03
Distribution: x64 Openbox
Location: Poland
Contact:

Re: Backing Up HDD to External Drive over USB 2.0

Post#3 by tome » 16 Jan 2017, 10:27

Try another target size, instead of 233 GiB use 1,9 TiB

beny
Full of knowledge
Full of knowledge
Posts: 729
Joined: 02 Jan 2011, 11:33
Location: italy

Re: Backing Up HDD to External Drive over USB 2.0

Post#4 by beny » 16 Jan 2017, 11:20

hi bogomips, install the exfat-utils first,i think you can't manage this hard disk size with fat 32 filesystem you need exfat that have no limit of size and after this gparted can check it...

User avatar
Ed_P
Contributor
Contributor
Posts: 3216
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 3.2.2 64-bit ISO
Location: Western NY, USA

Re: Backing Up HDD to External Drive over USB 2.0

Post#5 by Ed_P » 16 Jan 2017, 16:47

Personally I don't recommend reformatting a new drive. The vendor set it up this way for a reason and the clusters are probably aligned for performance. You reformat it you're on your own when it comes to support in some cases. Partitioning on the other hand I have no problem with. And on new machines I am careful to preserve the original sequence of the partitions. Years ago machine's hard drives had a single partition, now days new machines can have a half dozen of which only the C: drive is seen.
Ed

beny
Full of knowledge
Full of knowledge
Posts: 729
Joined: 02 Jan 2011, 11:33
Location: italy

Re: Backing Up HDD to External Drive over USB 2.0

Post#6 by beny » 16 Jan 2017, 18:55

hi, the exFAT-utils are like f2fs-tools without this software gparted do not show hard disk, formatted in this filesystem, why format the hard disk if this is clear?

Bogomips
Full of knowledge
Full of knowledge
Posts: 2562
Joined: 25 Jun 2014, 15:21
Distribution: 3.2.2 Cinnamon & KDE5
Location: London

Re: Backing Up HDD to External Drive over USB 2.0

Post#7 by Bogomips » 16 Jan 2017, 19:11

Ed_P wrote:As for no mention of Win 10 in the documentation to me would indicate the drive/manual were packaged 3 or more yrs ago.
Thinking along those lines being special offer, but as they seem to be such buddies with Micro$oft you'd think would have got pre-release copy for testing.
Ed_P wrote:Personally I don't recommend reformatting a new drive. The vendor set it up this way for a reason and the clusters are probably aligned for performance. You reformat it you're on your own when it comes to support in some cases. Partitioning on the other hand I have no problem with.
That's why not rushing things, As a first step being to shrink the FAT filesystem.
Ed_P wrote:Why do you want to partition it? Why can't you just create folders on it for your videos?
Videos was just special case. Main aim being to back up hdd of 250 GB, which weighs in at 232.88 GiB. Doing it in least expensive manner, computing power and memory wise:
  • Clone Drive:

    Code: Select all

    dd /dev/sda /dev/sdb2
  • rsync the Arch Way
Already each having to have partition of 233 GiB.
Ed_P wrote:
Bogomips wrote: but program insists on doing it.
What program?
KDE4 Partition Manager

Thanks tome,beny. Took a bit longer this time, before coming up with error after 6 secs. Also on GParted min and max partition size just differ by 9 MiB;
Image

Code: Select all

root@porteus:/home/guest# gdisk -l /dev/sdb
GPT fdisk (gdisk) version 1.0.0

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: not present


***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
***************************************************************

Disk /dev/sdb: 732566642 sectors, 2.7 TiB
Logical sector size: 4096 bytes
Disk identifier (GUID): ED6DD7B0-FB74-4469-B2C3-290123E431A0
Partition table holds up to 128 entries
First usable sector is 6, last usable sector is 732566636
Partitions will be aligned on 256-sector boundaries
Total free space is 2887 sectors (11.3 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1             256       732563999   2.7 TiB     0700  Microsoft basic data
Looks like Linux could be up to the task. So, should I put my faith in Linux and go the GPT Way? :unknown:
Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB

beny
Full of knowledge
Full of knowledge
Posts: 729
Joined: 02 Jan 2011, 11:33
Location: italy

Re: Backing Up HDD to External Drive over USB 2.0

Post#8 by beny » 16 Jan 2017, 19:33

dd used on a hard disk like your for 250 g of data you need gparted to refill the 2.5T that are lost: grey so not active, but when you connect this hard disk,what is the filesystem in porteus, but also in windows?

Bogomips
Full of knowledge
Full of knowledge
Posts: 2562
Joined: 25 Jun 2014, 15:21
Distribution: 3.2.2 Cinnamon & KDE5
Location: London

Re: Backing Up HDD to External Drive over USB 2.0

Post#9 by Bogomips » 16 Jan 2017, 19:59

That's right beny. If you look at the link article 4 yrs old, it recommends GParted. Also seen GParted has offered to create GPT partition table. No win$oze for me! Have in mind dd to unformatted partition and other ext2, the rest get GParted to unallocate for time being. :)
Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB

User avatar
Ed_P
Contributor
Contributor
Posts: 3216
Joined: 06 Feb 2013, 22:12
Distribution: Cinnamon 3.2.2 64-bit ISO
Location: Western NY, USA

Re: Backing Up HDD to External Drive over USB 2.0

Post#10 by Ed_P » 17 Jan 2017, 05:12

^ I'm confused. It sounds like you are copying your ext2 drive to USB drive. While I've never backed up a Linux formatted drive before all the backups I've done over the past few decades of FAT & NTFS drives were to compressed image files which could be stored anywhere. Does Linux/Porteus not have a backup/restore app that does that?

_update-

Actually there are several free apps for doing backups of Linux systems.

http://www.tecmint.com/linux-system-backup-tools/

sbackup & kbackup sound interesting.
Ed

tome
Contributor
Contributor
Posts: 562
Joined: 26 Jun 2013, 14:03
Distribution: x64 Openbox
Location: Poland
Contact:

Re: Backing Up HDD to External Drive over USB 2.0

Post#11 by tome » 17 Jan 2017, 08:21

Another "black" solution could be remove partition and add new smaller at the same start sector but another correct end sector by using fdisk, and next run fsck, try only if you don't have important data.

Bogomips
Full of knowledge
Full of knowledge
Posts: 2562
Joined: 25 Jun 2014, 15:21
Distribution: 3.2.2 Cinnamon & KDE5
Location: London

Re: Backing Up HDD to External Drive over USB 2.0

Post#12 by Bogomips » 17 Jan 2017, 11:07

Ed_P wrote:Actually there are several free apps for doing backups of Linux systems.
http://www.tecmint.com/linux-system-backup-tools/
sbackup & kbackup sound interesting.
Thanks for links. However prefer not to use apps if job can be done using basic tools. Have more control. 8)
Ed_P wrote:^ I'm confused. It sounds like you are copying your ext2 drive to USB drive. While I've never backed up a Linux formatted drive before all the backups I've done over the past few decades of FAT & NTFS drives were to compressed image files which could be stored anywhere.
Ya gotta think big! It's the whole shebang being copied/cloned to an unformatted partition.

Ed_P wrote:Does Linux/Porteus not have a backup/restore app that does that?
Yes, Porteus in copy2ram using dd. :) The ext2 formatted partition intended for separate backup using rsync. Thereby no call on computing power or memory, just time.
tome wrote:Another "black" solution could be remove partition and add new smaller at the same start sector but another correct end sector by using fdisk, and next run fsck, try only if you don't have important data.
Only have couple of trial ISO downloads. But first have to save the partition table. :wink:
but another correct end sector
Can you explain what you mean in more detail?
Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB

tome
Contributor
Contributor
Posts: 562
Joined: 26 Jun 2013, 14:03
Distribution: x64 Openbox
Location: Poland
Contact:

Re: Backing Up HDD to External Drive over USB 2.0

Post#13 by tome » 18 Jan 2017, 08:54

but another correct end sector
so all your important data are written to sectors before the end sector.

Bogomips
Full of knowledge
Full of knowledge
Posts: 2562
Joined: 25 Jun 2014, 15:21
Distribution: 3.2.2 Cinnamon & KDE5
Location: London

Re: Backing Up HDD to External Drive over USB 2.0

Post#14 by Bogomips » 19 Jan 2017, 00:14

Saving / Backing Up Partition Table
  • After some deeding came across exactly what was needed https://linuxaria.com/pills/how-to-clon ... ith-sfdisk and surprise! surprise! We already have it.
  • Dump Partition Table (text file). Very first priority!

    Code: Select all

    guest@porteus:~$ sudo /sbin/sfdisk --dump /dev/sdb > $g/sdb.dump
    sdb.dump:
    label: dos
    label-id: 0x6020b5f5
    device: /dev/sdb
    unit: sectors
    
    /dev/sdb1 : start=         256, size=   732563744, type=c
    
  • Dump Partition Table (binary file). Results in some perilous commands :shock:

    Code: Select all

    guest@porteus:~$ sudo /sbin/sfdisk -b /dev/sdb    
    
    Welcome to sfdisk (util-linux 2.27.1).                                                  
    Changes will remain in memory only, until you decide to write them.
    Be careful before using the write command.
    
    Checking that no-one is using this disk right now ... OK
    
    Backup files:
             MBR (offset     0, size   512): /root/sfdisk-sdb-0x00000000.bak
    
    Disk /dev/sdb: 2.7 TiB, 3000592965632 bytes, 732566642 sectors
    Units: sectors of 1 * 4096 = 4096 bytes
    Sector size (logical/physical): 4096 bytes / 4096 bytes
    I/O size (minimum/optimal): 32768 bytes / 268431360 bytes
    Disklabel type: dos
    Disk identifier: 0x6020b5f5
    
    Old situation:
    
    Device     Boot Start       End   Sectors  Size Id Type
    /dev/sdb1         256 732563999 732563744  2.7T  c W95 FAT32 (LBA)
    
    Type 'help' to get more information.
    
    >>> s
    unsupported command
    ...
     Commands:
       write    write table to disk and exit
       quit     show new situation and wait for user's feedback before write
       abort    exit sfdisk shell
       print    display the partition table
       help     show this help text
    
       Ctrl-D   the same as 'quit'
    >>> print
    
    Device     Boot Start       End   Sectors  Size Id Type
    /dev/sdb1         256 732563999 732563744  2.7T  c W95 FAT32 (LBA)
    >>> quit
    
    New situation:
    
    Device     Boot Start       End   Sectors  Size Id Type
    /dev/sdb1         256 732563999 732563744  2.7T  c W95 FAT32 (LBA)
    
    Do you want to write this to disk? [Y]es/[N]o: N
    Leaving.
    Good thing already dumped to text. Normally use quit to terminate program, but here abort needed! :twisted:
  • Partition Table Info

    Code: Select all

    guest@porteus:~$ sudo /sbin/sfdisk -J /dev/sdb > p10/tmp/sdb.js  # JSON fmt
    
    guest@porteus:~$ sudo /sbin/sfdisk -F /dev/sdb
    Unpartitioned space /dev/sdb: 0 B, 0 bytes, 0 sectors
    Units: sectors of 1 * 4096 = 4096 bytes
    Sector size (logical/physical): 4096 bytes / 4096 bytes
    
    guest@porteus:~$ sudo /sbin/sfdisk -g /dev/sdb
    /dev/sdb: 45600 cylinders, 255 heads, 63 sectors/track
    
tome's "black" solution
tome wrote:
but another correct end sector
so all your important data are written to sectors before the end sector.
Could not offhand immediately find out end of allocated space. As just have 2 ISOs as test, decided 20 GiB to be sufficiently beyond any write.
  • Shrinking Dump File to 20GiB

    Code: Select all

    sdb20G.dump:
    label: dos
    label-id: 0x6020b5f5
    device: /dev/sdb
    unit: sectors
    
    /dev/sdb1 : start=         256, size=   5242880, type=c
    
  • Applying to Partition

    Code: Select all

    root@porteus:/home/guest# sfdisk /dev/sdb < sdb20G.dump 
    Checking that no-one is using this disk right now ... OK
    
    Disk /dev/sdb: 2.7 TiB, 3000592965632 bytes, 732566642 sectors
    Units: sectors of 1 * 4096 = 4096 bytes
    Sector size (logical/physical): 4096 bytes / 4096 bytes
    I/O size (minimum/optimal): 32768 bytes / 268431360 bytes
    Disklabel type: dos
    Disk identifier: 0x6020b5f5
    
    Old situation:
    
    Device     Boot Start       End   Sectors  Size Id Type
    /dev/sdb1         256 732563999 732563744  2.7T  c W95 FAT32 (LBA)
    
    >>> Script header accepted.
    >>> Script header accepted.
    >>> Script header accepted.
    >>> Script header accepted.
    >>> Created a new DOS disklabel with disk identifier 0x6020b5f5.
    Created a new partition 1 of type 'W95 FAT32 (LBA)' and of size 20 GiB.
    /dev/sdb2: 
    New situation:
    
    Device     Boot Start     End Sectors Size Id Type
    /dev/sdb1         256 5243135 5242880  20G  c W95 FAT32 (LBA)
    
    The partition table has been altered.
    Calling ioctl() to re-read partition table.
    Syncing disks.
    
  • Fix the FS

    Code: Select all

    root@porteus:/home/guest# fsck.fat -awv /dev/sdb1
    fsck.fat 3.0.28 (2015-05-16)
    Checking we can access the last sector of the filesystem
    Seek to 3000581091328:Invalid argument
    
  • Checking Data Integrity

    Code: Select all

    uest@porteus:~$ mkdir x
    guest@porteus:~$ sudo mount /dev/sdb1 x
    guest@porteus:~$ ls x
    linuxmint-18.1-cinnamon-64bit.iso*  slackware-14.2-install-dvd.iso*
    
    guest@porteus:~$ sha256sum -b x/linuxmint-18.1-cinnamon-64bit.iso
    b99f4b98a1b41737ded072dc1a7060ca32224e23236074790d4fc86b51009e3c *x/linuxmint-18.1-cinnamon-64bit.iso
    
  • Displaying Amended Partition Table.

    Code: Select all

    guest@porteus:~$ sudo /sbin/gdisk -l /dev/sdb
    GPT fdisk (gdisk) version 1.0.0
    
    Partition table scan:
      MBR: MBR only
      BSD: not present
      APM: not present
      GPT: not present
    
    
    ***************************************************************
    Found invalid GPT and valid MBR; converting MBR to GPT format
    in memory. 
    ***************************************************************
    
    Disk /dev/sdb: 732566642 sectors, 2.7 TiB
    Logical sector size: 4096 bytes
    Disk identifier (GUID): BFE7D15B-2E70-4E67-9847-D4447EE2026E
    Partition table holds up to 128 entries
    First usable sector is 6, last usable sector is 732566636
    Partitions will be aligned on 256-sector boundaries
    Total free space is 727323751 sectors (2.7 TiB)
    
    Number  Start (sector)    End (sector)  Size       Code  Name
       1             256         5243135   20.0 GiB    0700  Microsoft basic data
    
Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB

Bogomips
Full of knowledge
Full of knowledge
Posts: 2562
Joined: 25 Jun 2014, 15:21
Distribution: 3.2.2 Cinnamon & KDE5
Location: London

Re: Backing Up HDD to External Drive over USB 2.0

Post#15 by Bogomips » 24 Jan 2017, 00:19

Partition Table GPT
  • Conversion to GPT

    Code: Select all

    root@porteus:/home/guest# gdisk /dev/sdb
    GPT fdisk (gdisk) version 1.0.0
    
    Partition table scan:
      MBR: MBR only
      BSD: not present
      APM: not present
      GPT: not present
    
    
    ***************************************************************
    Found invalid GPT and valid MBR; converting MBR to GPT format
    in memory. THIS OPERATION IS POTENTIALLY DESTRUCTIVE! Exit by
    typing 'q' if you don't want to convert your MBR partitions
    to GPT format!
    ***************************************************************
    ...
    Command (? for help): p
    Disk /dev/sdb: 732566642 sectors, 2.7 TiB
    Logical sector size: 4096 bytes
    Disk identifier (GUID): B6569275-EB0F-42A7-AAB0-6149AA346CC0
    Partition table holds up to 128 entries
    First usable sector is 6, last usable sector is 732566636
    Partitions will be aligned on 256-sector boundaries
    Total free space is 727323751 sectors (2.7 TiB)
    
    Number  Start (sector)    End (sector)  Size       Code  Name
       1             256         5243135   20.0 GiB    0700  Microsoft basic data
    
    Command (? for help): w
    
    Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
    PARTITIONS!!
    
    Do you want to proceed? (Y/N): y
    OK; writing new GUID partition table (GPT) to /dev/sdb.
    The operation has completed successfully.
    
  • Verification

    Code: Select all

    root@porteus:/home/guest# fdisk -l /dev/sdb
    Disk /dev/sdb: 2.7 TiB, 3000592965632 bytes, 732566642 sectors
    Units: sectors of 1 * 4096 = 4096 bytes
    Sector size (logical/physical): 4096 bytes / 4096 bytes
    I/O size (minimum/optimal): 32768 bytes / 268431360 bytes
    Disklabel type: gpt
    Disk identifier: B6569275-EB0F-42A7-AAB0-6149AA346CC0
    
    Device     Start     End Sectors Size Type
    /dev/sdb1    256 5243135 5242880  20G Microsoft basic data
    
  • INTERIM PARTITION TABLE & FURTHER PARTITION TABLE AMENDMENTS made thru CGDISK 's Curses Interface. No fancy GUI to further confuse matters.

    Code: Select all

    root@porteus:/home/guest# cgdisk /dev/sdb
    ...
    root@porteus:/home/guest# fdisk -l /dev/sdb
    Disk /dev/sdb: 2.7 TiB, 3000592965632 bytes, 732566642 sectors
    Units: sectors of 1 * 4096 = 4096 bytes
    Sector size (logical/physical): 4096 bytes / 4096 bytes
    I/O size (minimum/optimal): 32768 bytes / 268431360 bytes
    Disklabel type: gpt
    Disk identifier: B6569275-EB0F-42A7-AAB0-6149AA346CC0
    
    Device         Start       End  Sectors  Size Type
    /dev/sdb1        256   5243135  5242880   20G Microsoft basic data
    /dev/sdb2    5243136  61079807 55836672  213G Linux filesystem
    /dev/sdb3   61079808 122159359 61079552  233G Linux filesystem
    /dev/sdb4  122159360 201326847 79167488  302G Linux filesystem
    /dev/sdb5  201326848 206569727  5242880   20G Linux filesystem
    
  • SOME TIMINGS
    • Code: Select all

      root@porteus:/home/guest# time mkfs.ext2 -b 4096 /dev/sdb5
      mke2fs 1.43.1 (08-Jun-2016)
      Creating filesystem with 5242880 4k blocks and 1310720 inodes
      Filesystem UUID: ace9fec7-a440-4e94-b699-880728604465
      Superblock backups stored on blocks: 
              32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
              4096000
      
      Allocating group tables: done                            
      Writing inode tables: done                            
      Writing superblocks and filesystem accounting information: done   
      
      
      real    0m21.811s
      user    0m0.057s
      sys     0m0.794s
      
    • Code: Select all

      guest@porteus:~$ mkdir x y
      guest@porteus:~$ sudo mount /dev/sdb1 x
      guest@porteus:~$ sudo mount /dev/sdb5 y
      guest@porteus:~$ ls x
      linuxmint-18.1-cinnamon-64bit.iso*  slackware-14.2-install-dvd.iso*
      
      guest@porteus:~$ time cp -p x/*.iso y
      real    6m16.668s
      user    0m0.065s
      sys     0m18.473s
      
      guest@porteus:~$ time sha256sum y/linuxmint-18.1-cinnamon-64bit.iso 
      b99f4b98a1b41737ded072dc1a7060ca32224e23236074790d4fc86b51009e3c  y/linuxmint-18.1-cinnamon-64bit.iso
      real    1m12.518s
      user    0m23.252s
      sys     0m2.028s
      
  • Transitioning to Work Partition Table
    • Saving GPT prior to Amendment

      Code: Select all

      guest@porteus:~$ sudo /sbin/sfdisk --dump /dev/sdb > $g/exd/sdb5int.dump
      guest@porteus:~$ cat  $g/exd/sdb5int.dump
      label: gpt
      label-id: B6569275-EB0F-42A7-AAB0-6149AA346CC0
      device: /dev/sdb
      unit: sectors
      first-lba: 6
      last-lba: 732566636
      
      /dev/sdb1 : start=         256, size=     5242880, type=EBD0A0A2-B9E5-4433-87C0-68B6B72699C7, uuid=3CA7B25A-28AE-4F8A-A0A0-2B837B24C582, name="Microsoft basic data"
      /dev/sdb2 : start=     5243136, size=    55836672, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=E8E361BC-3E85-4C27-87F5-407390144E03, name="Reserved Space"
      /dev/sdb3 : start=    61079808, size=    61079552, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=00828806-EA41-4C42-A71F-66B5B6371F32, name="Cloned HDD"
      /dev/sdb4 : start=   122159360, size=    79167488, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=06F7862E-A17C-42FD-A4FF-907C06BD0CBC, name="Catch All"
      /dev/sdb5 : start=   201326848, size=     5242880, type=0FC63DAF-8483-4772-8E79-3D69D8477DE4, uuid=6954C2E1-26CA-4804-9D65-A7A71471FA50, name="Trial Ext2 Formatting FS"
      
    • Amending GPT using CGDISK

      Code: Select all

      root@porteus:/home/guest# cgdisk /dev/sdb
      root@porteus:/home/guest# fdisk -l /dev/sdb
      Disk /dev/sdb: 2.7 TiB, 3000592965632 bytes, 732566642 sectors
      Units: sectors of 1 * 4096 = 4096 bytes
      Sector size (logical/physical): 4096 bytes / 4096 bytes
      I/O size (minimum/optimal): 32768 bytes / 268431360 bytes
      Disklabel type: gpt
      Disk identifier: B6569275-EB0F-42A7-AAB0-6149AA346CC0
      
      Device         Start       End  Sectors  Size Type
      /dev/sdb1        256  61079807 61079552  233G Linux filesystem
      /dev/sdb2   61079808 122159359 61079552  233G Linux filesystem
      /dev/sdb3  122159360 201326847 79167488  302G Linux filesystem
      /dev/sdb5  201326848 206569727  5242880   20G Linux filesystem
      
    • Amending Partition Numbers (Risking loss of data held in last partition)

      Code: Select all

      root@porteus:/home/guest# cgdisk /dev/sdb
      root@porteus:/home/guest# fdisk -l /dev/sdb
      Disk /dev/sdb: 2.7 TiB, 3000592965632 bytes, 732566642 sectors
      Units: sectors of 1 * 4096 = 4096 bytes
      Sector size (logical/physical): 4096 bytes / 4096 bytes
      I/O size (minimum/optimal): 32768 bytes / 268431360 bytes
      Disklabel type: gpt
      Disk identifier: B6569275-EB0F-42A7-AAB0-6149AA346CC0
      
      Device         Start       End  Sectors  Size Type
      /dev/sdb1        256  61079807 61079552  233G Linux filesystem
      /dev/sdb2   61079808 122159359 61079552  233G Linux filesystem
      /dev/sdb3  122159360 201326847 79167488  302G Linux filesystem
      /dev/sdb4  201326848 206569727  5242880   20G Linux filesystem
      
    • Declaring the whole a Micro$oft Free Zone! :Yahoo!:

      Code: Select all

      root@porteus:/home/guest# time mkfs.ext2 -b 4096 /dev/sdb1
      mke2fs 1.43.1 (08-Jun-2016)
      /dev/sdb1 contains a vfat file system labelled 'INTENSO'
      Proceed anyway? (y,n) y
      Creating filesystem with 61079552 4k blocks and 15269888 inodes
      Filesystem UUID: 8f7e749f-00a3-4186-8332-4e146c0c0e8b
      Superblock backups stored on blocks: 
              32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
              4096000, 7962624, 11239424, 20480000, 23887872
      
      Allocating group tables: done                            
      Writing inode tables: done                            
      Writing superblocks and filesystem accounting information: done     
      
      
      real    3m8.182s
      user    0m0.112s
      sys     0m6.081s
      
Partition for Archiving of Videos & ISOs

    Code: Select all

    root@porteus:/home/guest# gdisk -l /dev/sdb
    GPT fdisk (gdisk) version 1.0.0
    
    Partition table scan:
      MBR: protective
      BSD: not present
      APM: not present
      GPT: present
    
    Found valid GPT with protective MBR; using GPT.
    Disk /dev/sdb: 732566642 sectors, 2.7 TiB
    Logical sector size: 4096 bytes
    Disk identifier (GUID): B6569275-EB0F-42A7-AAB0-6149AA346CC0
    Partition table holds up to 128 entries
    First usable sector is 6, last usable sector is 732566636
    Partitions will be aligned on 256-sector boundaries
    Total free space is 525997159 sectors (2.0 TiB)
    
    Number  Start (sector)    End (sector)  Size       Code  Name
       1             256        61079807   233.0 GiB   8300  rsync Back Up
       2        61079808       122159359   233.0 GiB   8300  Cloned HDD
       3       122159360       201326847   302.0 GiB   8300  Catch All
       4       201326848       206569727   20.0 GiB    8300  Trial Ext2 Formatti...
    
    Setting aside a 302 GiB Partition for this. Journalling not needed, so ext2 looks good. Expect to be able to fit in around 250 such files. So don't need many inodes. Settling for around 4000 to be on safe side. Issue creating ext2fs with desired parameters:
    • Inode every 64M

      Code: Select all

      root@porteus:/home/guest# mkfs.ext2 -b 4096 -m 0 -i 67108864 /dev/sdb3
      mke2fs 1.43.1 (08-Jun-2016)
      Creating filesystem with 79167488 4k blocks and 38656 inodes
      Filesystem UUID: 3aab194d-8ef5-4905-bbdc-748fdf507674
      Superblock backups stored on blocks: 
              32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
              4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968
      
      Allocating group tables: done                            
      Writing inode tables: done                            
      Writing superblocks and filesystem accounting information: done
      Expect just 16 x 302 = 4832 inodes. However have 38656 inodes, giving 8M per inode.
    • Inode every 512M

      Code: Select all

      root@porteus:/home/guest# mkfs.ext2 -b 4096 -m 0 -i 536870912 /dev/sdb3
      mkfs.ext2: invalid inode ratio 536870912 (min 1024/max 67108864)
      Confirming Inode every 64M to be Valid Value
    • Inode every 48M (Trying ext4)

      Code: Select all

      root@porteus:/home/guest# time mkfs.ext4 -b 4096 -m0 -i50331648 /dev/sdb3 
      mke2fs 1.43.1 (08-Jun-2016)
      /dev/sdb3 contains a ext2 file system
              created on Sun Jan 22 16:10:58 2017
      Proceed anyway? (y,n) y
      Creating filesystem with 79167488 4k blocks and 38656 inodes
      Filesystem UUID: 2671309d-1c79-455a-9a6b-b9cfd879eb25
      Superblock backups stored on blocks: 
              32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
              4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968
      
      Allocating group tables: done                            
      Writing inode tables: done                            
      Creating journal (32768 blocks): done
      Writing superblocks and filesystem accounting information: done     
      
      
      real    0m20.955s
      user    0m0.028s
      sys     0m0.457s
      
      No improvement. Stuck on 38656 inodes!
    • Directly Specifying Desired Number of Inodes (supposed to override bytes to inode ratio)

      Code: Select all

      root@porteus:/home/guest# time mkfs.ext2 -b 4096 -m0 -N4096 /dev/sdb3
      mke2fs 1.43.1 (08-Jun-2016)
      /dev/sdb3 contains a ext4 file system
              last mounted on Sun Jan 22 17:23:19 2017
      Proceed anyway? (y,n) y
      Creating filesystem with 79167488 4k blocks and 38656 inodes
      Filesystem UUID: b48aacde-ee9f-4ed5-ab6c-ad09bfa8aca3
      Superblock backups stored on blocks: 
              32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
              4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968
      
      Allocating group tables: done                            
      Writing inode tables: done                            
      Writing superblocks and filesystem accounting information: done     
      
      
      real    0m32.970s
      user    0m0.029s
      sys     0m0.282s
      
      Still 38656 inodes. No override!
    • Different Tack

      Code: Select all

      root@porteus:/home/guest# time mkfs.ext2 -b 8192 -m0 -N 4096 /dev/sdb3
      Warning: blocksize 8192 not usable on most systems.
      mke2fs 1.43.1 (08-Jun-2016)
      /dev/sdb3 contains a ext2 file system
              created on Sun Jan 22 21:30:13 2017
      Proceed anyway? (y,n) y
      mkfs.ext2: 8192-byte blocks too big for system (max 4096)
      Proceed anyway? (y,n) y
      Warning: 8192-byte blocks too big for system (max 4096), forced to continue
      Creating filesystem with 39583744 8k blocks and 19360 inodes
      Filesystem UUID: 40711675-e673-4a14-a9cf-66403251f442
      Superblock backups stored on blocks: 
              65528, 196584, 327640, 458696, 589752, 1638200, 1769256, 3210872, 
              5307768, 8191000, 15923304, 22476104
      
      Allocating group tables: done                            
      Writing inode tables: done                            
      Writing superblocks and filesystem accounting information: done   
      
      
      real    0m35.978s
      user    0m0.017s
      sys     0m0.127s
      
      Halving number of inodes by doubling block size seems to work, but seems not to be viable. :unknown:
    Looks like there is a hard coded limitation being imposed. :twisted:
    Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
    NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB

    Post Reply