100GB of space lost?

Can you provide the output of fdisk -l, or a screenshot of gparted?

gparted doesn't show much information. (the partition can't unmount, it is mounted by root)

"fdisk -l" exits immediately without providing any output

koen@koen-desktop:~$ cat /proc/partitions
major minor #blocks name

   8 0 312571224 sda
   8 1 102400 sda1
   8 2 21504000 sda2
   8 3 1 sda3
   8 5 12595198 sda5
   8 6 4095958 sda6
   8 7 274272238 sda7
   8 16 976762584 sdb
   8 48 4054016 sdd
   8 49 4052992 sdd1
   8 64 15520768 sde
   8 65 15520764 sde1

maybe this is the info you need?

Sorry, "sudo fdisk -l"

It needs to be run as admin.

koen@koen-desktop:~$ sudo fdisk -l

Schijf /dev/sda: 320.1 GB, 320072933376 bytes
255 koppen, 63 sectoren/spoor, 38913 cilinders
Eenheid = cilinders van 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Schijf-ID: 0x0003f011

 Apparaat Opstart Begin Einde Blokken ID Systeem
/dev/sda1 * 1 13 102400 7 HPFS/NTFS
Partitie 1 eindigt niet op een cilindergrens.
/dev/sda2 13 2690 21504000 7 HPFS/NTFS
Partitie 2 eindigt niet op een cilindergrens.
/dev/sda3 2691 38914 290963760 5 Uitgebreid
Partitie 3 eindigt niet op een cilindergrens.
/dev/sda5 2691 4259 12595198 83 Linux
/dev/sda6 4259 4768 4095958 82 Linux wisselgeheugen
/dev/sda7 4768 38914 274272238 83 Linux

Schijf /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 koppen, 63 sectoren/spoor, 121601 cilinders
Eenheid = cilinders van 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Schijf-ID: 0x00000000

Schijf /dev/sdb bevat geen geldige partitietabel

the terminal-output is in dutch.
the last line is saying that /dev/sdb does not have an valid partitiontabel.

Well, a good chunk of your drive is being used for an NTFS partition, and I assume that "wisselgeheugen" means "swap"?

indeed "wisselgeheugen" is dutch for "swap".

there is a small misunderstanding here, i realize i wasn't clear about it.

my dev/sda is perfectly fine, it is a dual-boot of Ubuntu and windows with a sapperate /home.

my problem is /dev/sdb
it is a new internal harddisk(1 Terabyte), used for backup only. it has a label "TeraBackup" and it is formatted ext2-only(it came blank)
harddisk-tools is telling me it is "Not partitionet", meaning it has no MBR. just 1 big ext2 partition
it is mounted by fstab on /mnt/TeraBackup/

now, nautilus is giving me contradicting information
it says the files on /mnt/TeraBackup/ are using 144,1GB
yet, there is only 652,7GB of free space.
i also checked the Lost+found folder, nothing is in there.

so, 144,1(used space) + 652,7(free space) = 796,8GB
yet, it is an Terabyte-harddisk, it should have something near 1000GB

i am looking for that lost space. harddisk-tools is also reporting the correct size. (1000204886016 bytes exactly)

sry for the misunderstanding, i just realize that a bunch of terminal-output isn't clear information at all.

> sry for the misunderstanding, i just realize that a bunch of terminal-output isn't clear information at all.

OK, I thought you were talking about /dev/sda..

It is odd that you don't have a partition table for that drive (sdb)... Something is not adding up -- without a partition table, you could not have made the screenshot you showed.

the fdisk output shows that the 1TB drive was, at the time of posting, completely blank. Can you repeat the fdisk output with the formatted drive in place?

As an aside, note that Ext also keeps 5% reserved for the root user
from mke2fs (man mke2fs):

       -m reserved-blocks-percentage
              Specify the percentage of the filesystem blocks reserved for the
              super-user. This avoids fragmentation, and allows root-owned
              daemons, such as syslogd(8), to continue to function correctly
              after non-privileged processes are prevented from writing to the
              filesystem. The default percentage is 5%.

So you lose 50GB here automatically (I don't think this will be counted in your used space, but will be unavailable)

Wait..

/dev/sdb /mnt/TeraBackup ext2 defaults 0 3

this is not right... You should have partitioned your device, even with a single large partition... This may be what is causing the misreported file size -- you are trying to use it directly as a single block device. This could be very confusing to any software trying to interpret disk capacities.

alright, when i got time, i will repartition the whole thing. (got lucky, stil got the old-harddisk, so it won't cause any problems)

i wil report back whether it was succesfull or not.

just one thing i am curious about, it put the "pass" in fstab to 3. this means the drive wil be checked as last one right? (first / then /home en then /mnt/terabackup )

i kinda assumed that without really knowing.

I honestly don;t keep all these things in my head :)

man fstab says:

The sixth field, (fs_passno), is used by the fsck(8) program to deter-
       mine the order in which filesystem checks are done at reboot time. The
       root filesystem should be specified with a fs_passno of 1, and other
       filesystems should have a fs_passno of 2. Filesystems within a drive
       will be checked sequentially, but filesystems on different drives will
       be checked at the same time to utilize parallelism available in the
       hardware. If the sixth field is not present or zero, a value of zero
       is returned and fsck will assume that the filesystem does not need to
       be checked.

So basically 3 will mean that it will wait for its turn (third round) when it neeeds to be checked Note that the check count is time or mount based.

alright, that seems to be working now.

reported disk-space is now correct, and i dit "sudo tune2fs -m 0 /dev/sdb1" to make the reserved space free.

new problem pops up: now the disk is used for 14GB, but i do not see any files in it.

that is not really a problem, just want to understand why. so i mark this as solved!

thank you very much for your time, mycae. i really appreciate the support.

There is some overhead in maintaining the filesystem structure... I am insufficiently familiar with the filesystem design to be able to account for it.