Well after playing with # bytes / inode on the latest
drive install proved to change nothing.
I tried createing a newfs (since the original were created
with 4.0d but were being run now on 3.2c), did nothing to
fix the space problem.
Finally, I decided to go through my Database directories
one by one using du and sorting the output highest down
to find the files that were way higher than they should be.
Both should have been about 4 or 5 megs, but they were
unsparsed to about 2gb each
It came down to 2 files which must have been corupted
and were sparse files, and when I copied them over the
sparseness was nomore.
After removing the 2 offending files, my disk space went
from 73% full on on one fs down to 19%
and the other went from 59% down to 17%
So in the end it was the sparse files, had NOTHING to
do with the filesystems, how they were created and with
what O/S they were created with.
Well....I learned a whole lot about UFS file systems :)
Again, thank you to Dr. Tom Blinn & Alan _at_ Nabeth for all
the time and info and scenarios that were bounced back and
forth.
Now I can go home.
George
>-----Original Message-----
>From: George Gallen [mailto:ggallen_at_slackinc.com]
>Sent: Tuesday, June 27, 2000 3:57 PM
>To: 'tru64-unix-managers_at_ornl.gov'
>Subject: another partial summary: Where'd my disk space go?
>
>
>Another possibility was that I had some sparse files,
>but after looking at one of my original fs still on
>the system (doing an ls -ls), I didn't see any mismatches
>in sizes, so I doubt our DBMS is creating sparse files.
>
>After looking more and more into the parameters of the
>fs, it looks more like that's where the problems lies.
>
>I'll have to try making a new filesystem and toying
>with parameters such as bytes/inode, or # cyl/group and
>lastly if all else fails possibly playing with the
>disk geometry (uggg)
>
>Many Thanks to Dr. Tom Blinn and Alan _at_ nabeth for some
>tips and info into investigating this further.
>
>There doesn't seem to be any corruption with the data
>so I doubt that's the problem, so next time I convert a
>drive (probably later this week or next) I can play with
>the settings on those file systems and see what I get.
>
>George Gallen
>
>George Gallen
>Senior Programmer/Analyst
>Accounting/Data Division
>ggallen_at_slackinc.com
>ph:856.848.1000 Ext 220
>
>SLACK Incorporated - An innovative information, education and
>management
>company
>http://www.slackinc.com
>
>
>>-----Original Message-----
>>From: George Gallen [mailto:ggallen_at_slackinc.com]
>>Sent: Tuesday, June 27, 2000 11:10 AM
>>To: 'tru64-unix-managers_at_ornl.gov'
>>Subject: partial summary: Where'd my disk space go? (more info)
>>
>>
>>The feeling seems to be using a large file system
>>under 3.2c may be where the problem lies. Since
>>the disklabel seems ok, I'll have to check into
>>the tunefs/newfs parameters to know more.
>>
>>Thanks for the replies
>>George
>>
>>>-----Original Message-----
>>>From: George Gallen [mailto:ggallen_at_slackinc.com]
>>>Sent: Tuesday, June 27, 2000 10:44 AM
>>>To: 'tru64-unix-managers_at_ornl.gov'
>>>Subject: Where'd my disk space go? (more info)
>>>
>>>
>>>Not sure if this matters...
>>>
>>>I created the filesystems for the new drives using 4.0d, but
>>>right now the drives are being used in 3.2c. Should I have
>>>reformatted the drives under 3.2c? The disklabel read fine
>>>and the filesystem seemed(?) to work without problems.....
>>>then again...
>>>
>>>George
>>>
>>>>-----Original Message-----
>>>>From: George Gallen [mailto:ggallen_at_slackinc.com]
>>>>Sent: Tuesday, June 27, 2000 10:26 AM
>>>>To: 'tru64-unix-managers_at_ornl.gov'
>>>>Subject: Where'd my disk space go? (more info)
>>>>
>>>>
>>>>After I restored the data that resided on one partition of
>>>>the rz28 (apx 1gb) onto the partition of rz1df (apx 4gb)
>>>>I ran (du -k -s) and it showed 2.7gb. Now that 2.7gb of
>>>>files came from a filesystem of about 1gb by doing a
>>>>cp -Rp rz28partition rz1dfpartition.
>>>>
>>>>Would changing the partition size from 1gb to 4gb, change
>>>>the minimum amount of drive space required for "each" file
>>>>that much it would increase in size by 1.7gb?
>>>>
>>>>Yes, I do realize these drives are not partitioned for their
>>>>full capacity, as some have pointed out.
>>>>
>>>>Thanks
>>>>George
>>>>
>>>>>-----Original Message-----
>>>>>From: George Gallen [mailto:ggallen_at_slackinc.com]
>>>>>Sent: Monday, June 26, 2000 10:58 PM
>>>>>To: 'tru64-unix-managers_at_ornl.gov'
>>>>>Subject: Where'd my disk space go?
>>>>>
>>>>>
>>>>>Is this "problem" related to an increase in inodes?
>>>>>
>>>>>I replaced a 2.1gb with 2 filesystems (ufs) each apx 1gb each
>>>>>with a 9.1 gb with 2 filessystems (ufs) each apx 4gb each
>>>>>
>>>>>Replaced rz28's with rz1df's
>>>>>
>>>>>Now my 2.1 filesystems were about 80 & 90 % full when I
>>>>>replaced the drives
>>>>>Now my 9.1 filesystems are about 50 & 70 % full.
>>>>>
>>>>>Why didn't the new filesystems go to around 20 & 25 % full? I
>>>>increased
>>>>>the avail space by a factor of 4, wouldn't the % of used
>>>>space decrease
>>>>>by a factor of 4?
>>>>>
>>>>>sample disklabel from the rz28 still on the system:
>>>>>
>>>>># /dev/rrz1a:
>>>>>type: SCSI
>>>>>disk: RZ28B
>>>>>label:
>>>>>flags:
>>>>>bytes/sector: 512
>>>>>sectors/track: 99
>>>>>tracks/cylinder: 16
>>>>>sectors/cylinder: 1584
>>>>>cylinders: 2595
>>>>>sectors/unit: 4110480
>>>>>rpm: 3600
>>>>>interleave: 1
>>>>>trackskew: 0
>>>>>cylinderskew: 0
>>>>>headswitch: 0 # milliseconds
>>>>>track-to-track seek: 0 # milliseconds
>>>>>drivedata: 0
>>>>>
>>>>>8 partitions:
>>>>># size offset fstype [fsize bsize cpg]
>>>>> a: 131072 0 unused 1024 8192 #
>>>>>(Cyl. 0 - 82*)
>>>>> b: 401408 131072 unused 1024 8192 #
>>>>>(Cyl. 82*- 336*)
>>>>>
>>>>> c: 4110480 0 unused 1024 8192 #
>>>>>(Cyl. 0 - 2594)
>>>>> d: 1191936 532480 unused 1024 8192 #
>>>(Cyl. 336*-
>>>>>1088*)
>>>>> e: 1191936 1724416 unused 1024 8192 #
>>>(Cyl. 1088*-
>>>>>1841*)
>>>>> f: 1194128 2916352 unused 1024 8192 #
>>>(Cyl. 1841*-
>>>>>2594*)
>>>>> g: 1787904 532480 4.2BSD 1024 8192 16 #
>>>(Cyl. 336*-
>>>>>1464*)
>>>>> h: 1790096 2320384 4.2BSD 1024 8192 16 #
>>>(Cyl. 1464*-
>>>>>2594*)
>>>>>
>>>>>
>>>>>sample disklabel from the rz1df on the system now:
>>>>>
>>>>># /dev/rrz2a:
>>>>>type: SCSI
>>>>>disk: RZ1DF-CB
>>>>>label:
>>>>>flags: dynamic_geometry
>>>>>bytes/sector: 512
>>>>>sectors/track: 168
>>>>>tracks/cylinder: 20
>>>>>sectors/cylinder: 3360
>>>>>cylinders: 5273
>>>>>sectors/unit: 17773524
>>>>>rpm: 7200
>>>>>interleave: 1
>>>>>trackskew: 28
>>>>>cylinderskew: 72
>>>>>headswitch: 0 # milliseconds
>>>>>track-to-track seek: 0 # milliseconds
>>>>>drivedata: 0
>>>>>
>>>>>8 partitions:
>>>>># size offset fstype [fsize bsize cpg]
>>>>> a: 131072 0 4.2BSD 1024 8192 16 #
>>>>>(Cyl. 0 - 39*)
>>>>> b: 262144 131072 unused 0 0 #
>>>>>(Cyl. 39*- 117*)
>>>>>
>>>>> c: 17773524 0 unused 0 0 #
>>>>(Cyl. 0 -
>>>>>5289*)
>>>>> d: 0 0 unused 0 0 #
>>>>>(Cyl. 0 - -1)
>>>>> e: 0 0 unused 0 0 #
>>>>>(Cyl. 0 - -1)
>>>>> f: 0 0 unused 0 0 #
>>>>>(Cyl. 0 - -1)
>>>>> g: 8690154 393216 4.2BSD 1024 8192 16 #
>>>(Cyl. 117*-
>>>>>2703*)
>>>>> h: 8690154 9083370 4.2BSD 1024 8192 16 #
>>>(Cyl. 2703*-
>>>>>5289*)
>>>>>
>>>>>Currently running 3.2c
>>>>>
>>>>>Thanks
>>>>>George
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>George Gallen
>>>>>Senior Programmer/Analyst
>>>>>Accounting/Data Division
>>>>>ggallen_at_slackinc.com
>>>>>ph:856.848.1000 Ext 220
>>>>>
>>>>>SLACK Incorporated - An innovative information, education and
>>>>>management
>>>>>company
>>>>>http://www.slackinc.com
>>>>>
>>>>
>>>
>>
>
Received on Wed Jun 28 2000 - 04:47:57 NZST