MandrivaClub.NL > dd: maximale bestandsgrootte?

wimedel

Aug 29 2007, 06:25 PM

Ik wil proberen gedelete bestanden van een harde schijf m.b.v. foremost weer naar voren te halen. Daarvoor moet ik een dump maken van de betreffende schijf (een Maxtor van 78Gb). Dat dacht ik te kunnen doen met het commando (als root):

dd if=/dev/hdb1 of=/home/restore/dump.bin

Hierbij is hdb1 de te recoveren partitie (de hele schijf was als één partitie ingedeeld) en dump.bin de naam van de te maken dump.
/home heeft een aparte partitie met bijna 105 Gb vrije ruimte.
Het maken van dump.bin begint wel, maar eindigt als het bestand een grootte van ca 16,1 Gb heeft, met de melding dat het bestand te groot is. Maar op dat moment is er nog bijna 90 Gb vrije ruimte in /home.
Wat heb ik hierbij over het hoofd gezien?
Overigens haalt foremost uit het stukje dump.bin allerlei bestanden waarvan ik het bestaan helemaal niet vermoedde (het was een tweedehands schijf)!
Wim

HighKing

Aug 29 2007, 06:59 PM

Volgens dit document op Wikipedia kan ext3 (ervanuit gaande dat de partitie daarmee is geformaateerd, want dat zeg je er niet bij) niet groter dan 16GB per bestand aan bij 1KB blocks.
Vermoedelijk zit daar dan ook je probleem...

Ik heb dit zelf nooit aan de hand gehaald... wellicht is het mogelijk om de partitie te herformatteren met 2KB blocks. Dan heb je wel iets meer last van slack (nog steeds nihil), maar kun je er vrolijk een bestand van 256GB op ploffen.

wimedel

Aug 29 2007, 10:04 PM

(HighKing @ Aug 29 2007, 05:59 PM) [snapback]88937[/snapback]

Volgens dit document op Wikipedia kan ext3 (ervanuit gaande dat de partitie daarmee is geformaateerd, want dat zeg je er niet bij) niet groter dan 16GB per bestand aan bij 1KB blocks.
Vermoedelijk zit daar dan ook je probleem...

Ik heb dit zelf nooit aan de hand gehaald... wellicht is het mogelijk om de partitie te herformatteren met 2KB blocks. Dan heb je wel iets meer last van slack (nog steeds nihil), maar kun je er vrolijk een bestand van 256GB op ploffen.

Na lezing van de wiki denk ik inderdaad dat daar het probleem zit. Ik zou het kunnen proberen, maar ik kan met de resterende inhoud van de partitie nergens anders naar toe op mijn pc. En om m'n home-bestanden nu tijdelijk ergens anders "op te bergen" voor een actie waarvan het eindresultaat sowieso twijfelachtig is, voel ik niets.
Als de slack zo gering is, waarom zouden we dan niet standaard een grotere blocksize kiezen? Dan kan je bijv. ook grote gecomprimeerde backupbestanden makkelijk kwijt (ik begrijp nu, waarom dat tot nu toe niet lukte).
Wim

kris

Aug 29 2007, 11:18 PM

De bocksize op mijn ext3 partities op MDV is standaard 4kB.

CODE

[chris@shuttle ~]$ su
Password:
[root@shuttle chris]# tune2fs -l /dev/sda8
tune2fs 1.39 (29-May-2006)
Filesystem volume name:   MCNLIVE
Last mounted on:          <not available>
Filesystem UUID:          6275219a-99f0-488d-bc21-c7006b35a6ac
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal resize_inode dir_index filetype needs_recovery sparse_super large_file
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              2611200
Block count:              5221117
Reserved block count:     261055
Free blocks:              3334529
Free inodes:              2611186
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16320
Inode blocks per group:   510
Filesystem created:       Sat May 12 15:06:08 2007
Last mount time:          Thu Aug 30 00:08:44 2007
Last write time:          Thu Aug 30 00:08:44 2007
Mount count:              109
Maximum mount count:      -1
Last checked:             Sat May 12 15:06:08 2007
Check interval:           0 (<none>)
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      42839b13-9f1a-4159-ae5b-2af0720e0eb6
Journal backup:           inode blocks
[root@shuttle chris]#