LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (https://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   Text Size and drive capacity problem with SUSE 10.0 (https://www.linuxquestions.org/questions/linux-newbie-8/text-size-and-drive-capacity-problem-with-suse-10-0-a-511610/)

Robert Diggs 12-18-2006 09:20 AM

Text Size and drive capacity problem with SUSE 10.0
 
Hey World,

I have two questoins, one of which I already know the answer to I think. First one is I'm having some text display problems. I've gone into the control center and adjusted all text sizes, but it didn't adjust ALL of them. When I was attempt to run GIMP for the first time, the text on the install window was too small to read. This happens in other windows, but not all of them. One of the other key ones is in the login window. I have automatic login setup, but I just stumbled across that one. It's not crucial that this one gets fixed (the login screen I mean).

Second problem is I have a 320GB drive. SUSE only recognizes up to 297.1GB. Any ideas on what I can do, or do I have to live with it?

saikee 12-18-2006 11:43 AM

I think some programs allow you to adjust the fonts but others may not. If you have a difficulty in reading the desktop it may be the resolution you have set is too refined.

When a PC user formats a hard disk with a specified filing system (OK you didn't do it or didn't know as the installer did it for you) some areas are set aside for the boot loader and the filing indexing system. Also there is 1024 bytes in one kilobyte (used by the filing system) and the combined effect is the usable space is always smaller than the raw disk size. It is the overhead a PC user must pay. Getting 93% out of the raw size is not too far off.

Robert Diggs 12-18-2006 02:19 PM

I didn't realize that the filing system took up space. The only thing that I'm concerned about is way back when hard drives were first being sold, they were being advertised with X amount of space and then it was SIGNIFICANTLY less after formatting. Eventually, consumers complained enough and this was changed. They changed it to where the size advertised was after formatting. I could be misunderstood here, I have been before, but 23GB missing? That sounds like an awful lot to lose after formatting.

In my experience with Windows XP, I think before SP1, it wouldn't recognize a drive above 137GB. I could understand if there is a problem like that with SUSE. Something just seems off to me, though.

If what you said is infact true, should I repartition it for smaller partitions so I lose a lower percentage per GB per partition? Nothing too dramatic, but split it up into a few partitions. I just did one big partition.

saikee 12-18-2006 06:00 PM

I don't think you gain much by chopping the disks up in small partitions.

You may have a different opinion of the overhead required if someone ask you to keep a record of files in a fully populated 297Gb hard disk.

chrism01 12-18-2006 07:27 PM

There's also a post around here somewhere that points out that physically disk sizes are measured in powers of 2 (as you'd expect), but manufacturers and/or sales people tend to use powers of 10.
As the (actual) disk size increases, the difference between the 2 descriptions increases.

xjlittle 12-18-2006 10:05 PM

You can leave your disk the same size if you want. Since you're using SuSE I'm guessing you have the reiserfs file system. What's consuming your disk space is the size of the journal. There are a couple of ways that you can change this The first way is to adjust the block size when formatting the disk. Have a look at the following.

This is with the standard format:
Code:

root@john-fc6 jslittl]# /sbin/mkfs.reiserfs /dev/sda9

Guessing about desired format.. Kernel 2.6.18-1.2849.fc6 is running.
Format 3.6 with standard journal
Count of blocks on the device: 524112
Number of blocks consumed by mkreiserfs formatting process: 8227
==>>Blocksize: 4096
Hash function used to sort names: "r5"
==>>Journal Size 8193 blocks (first block 18)
==>>Journal Max transaction length 1024
inode generation number: 0
UUID: 74067bf3-3c1a-4c47-a809-39de4593deab
ATTENTION: YOU SHOULD REBOOT AFTER FDISK!
        ALL DATA WILL BE LOST ON '/dev/sda9'!
Continue (y/n):y
Initializing journal - 0%....20%....40%....60%....80%....100%
Syncing..ok

ReiserFS is successfully created on /dev/sda9.
[root@john-fc6 jslittl]#

On a 2GB file system notice that the block size is 4096, the journal size is 8193 blocks and the max transaction length is 1024. A check of gparted shows 32.14MB used.

Now when I adjust the block size at format:

Code:


[root@john-fc6 jslittl]# /sbin/mkfs.reiserfs -b 1024 /dev/sda9

Guessing about desired format.. Kernel 2.6.18-1.2849.fc6 is running.
Format 3.6 with standard journal
Count of blocks on the device: 2096448
Number of blocks consumed by mkreiserfs formatting process: 8448
==>>Blocksize: 1024
Hash function used to sort names: "r5"
==>>Journal Size 8126 blocks (first block 66)
==>>Journal Max transaction length 256
inode generation number: 0
UUID: 7ee7bd1e-0174-41ec-9036-5d6692f8a0ef
ATTENTION: YOU SHOULD REBOOT AFTER FDISK!
        ALL DATA WILL BE LOST ON '/dev/sda9'!
Continue (y/n):y
Initializing journal - 0%....20%....40%....60%....80%....100%
Syncing..ok

By using a 1024 block I've cut my block size by 25% as well as my max journal transaction length. This in turn gives me 8.25MB used per gparted on a 2GB disk.

Perhaps the easiest way though is just to use the --journal-size option:

Code:

[root@john-fc6 jslittl]# /sbin/mkfs.reiserfs --journal-size 520 /dev/sda9

Guessing about desired format.. Kernel 2.6.18-1.2849.fc6 is running.
Format 3.6 with non-standard journal
Count of blocks on the device: 524112
Number of blocks consumed by mkreiserfs formatting process: 554
==>>Blocksize: 4096
Hash function used to sort names: "r5"
==>>Journal Size 520 blocks (first block 18)
==>>Journal Max transaction length 259
inode generation number: 0
UUID: 4d7f44d7-b952-4c71-91c3-e3e9fdd59b94
ATTENTION: YOU SHOULD REBOOT AFTER FDISK!
        ALL DATA WILL BE LOST ON '/dev/sda9'!
Continue (y/n):y
Initializing journal - 0%....20%....40%....60%....80%....100%
Syncing..ok

Tell your friends to use a kernel based on 2.4.18 or later, and especially not a
kernel based on 2.4.9, when you use reiserFS. Have fun.

ReiserFS is successfully created on /dev/sda9.

By doing this I've kept my block size at the standard 4096 but reduced my disk useage for the journal to 2.17MB used per gparted.

hth

shorty943 12-18-2006 10:38 PM

Chrism01. You hit the nail right on the head. Don't get me wrong and start a flame war guys. The in depth tech answer, correct as it is, is not for the newbies. Try this. The corporation is only interested in sales. If they can con someone into thinking they will get more for less, they will. Heads, sectors and cylinders, multiply by the decimal 1000/ heads sectors and cylinders, multiply by the binary 1024. Grab a calculator, a pencil and paper, a thumb nail dipped in blood, and do the simple math. The answer is still the same, the corp cons and the poor confused newbie cries what the freak is going on.

I hope this rather cynical view of the corporate snow job enlightens you Rob.

christmas wishes to all.

shorty-( the cynical) in Australia.

Registered Linux User 437639

Wim Sturkenboom 12-18-2006 11:14 PM

Maybe the following can help in future with regards to disksize:

As explained above, HD manufacturers use 1000 bytes instead of 1024 bytes for a kilobyte (so it sounds as if the HD is bigger).
If your HD capacity is expressed in
  • kilobytes, the actual size is 1000/1024 is 97.7 %
  • megabytes, the actual size is 1000/1024 * 1000/1024 is 95.4 %
  • gigabytes, the actual size is 1000/1024 * 1000/1024 * 1000/1024 is 93.1 %
  • terabytes, the actual size is 1000/1024 * 1000/1024 * 1000/1024 * 1000/1024 is 90.9 %
Apply the above percentages to your specified HD capacity to calculate the capacity seen by the computer (for 320GB, you end up with 297GB).

Above applies to unformatted disks.

Robert Diggs 12-19-2006 07:38 AM

Thanks
 
Thanks a lot for the input guys. Xjlittle, thanks for the tip. I may just start over to utilize the demonstration you gave. It doesn't increase capacity perse, but it decreases the effect that formatting has. Again, thank you guys for the learning experience.

Regards,

Brandon


All times are GMT -5. The time now is 06:29 AM.