[Tar] tar: home.tar: Wrote only 0 of 10240 bytes

[jep]

Hoi,

Ik heb op meerdere Debian GNU/Linux 3.0 machines met kernel 2.4.2* het zelfde probleem met backups over NFS. Heeft iemand enig idee wat hier mis is?

Ik krijg de volgende error:

tar: home.tar: Wrote only 0 of 10240 bytes
tar: Error is not recoverable: exiting now

Ik gebruik NFS v3 en gooi gewoon een heleboel files in een tar. Niets geks. Ik gebruik hiervoor tar cf home.tar /home

Iemand enige clue? Ik heb het dus op een aantal Debian machines. RedHat dozen backuppen zonder problemen.

[Verwijderd]

Zeker weten dat de betreffende partitie niet vol staat?

[ Voor 24% gewijzigd door Verwijderd op 01-11-2003 00:16 . Reden: FS != partitie |:( ]

[kenneth]

Andere inkopper: je working directory is toevallig niet /home

[jep]

Nee, nee . Het is ook op alle machines precies dezelfde error.

code:

shell:/backups/shell# time tar cf home.tar /home/*
tar: Removing leading `/' from member names
tar: home.tar: Wrote only 0 of 10240 bytes
tar: Error is not recoverable: exiting now

real    15m29.603s
user    0m2.630s
sys     0m25.770s
shell:/backups/shell# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda4              18G  6.2G   11G  37% /
/dev/hda1              56G   20G   33G  38% /home
/dev/hda3             471M  8.1M  439M   2% /tmp
vuurdoos:/backup      177G  3.3G  165G   2% /backups
shell:/backups/shell#

[ Voor 7% gewijzigd door jep op 01-11-2003 00:23 ]

[Verwijderd]

Mjah die opmerking over het feit dat er namen inzitten die beginnen met ' =(') is sowieso wel opmerkelijk.

Al eens geprobeerd of hij het wel doet wanneer deze bestanden/dirs overgeslagen worden?

Verder zou ik strace er denk ik maar even op los laten als je er niet achterkomt

edit:

Woei, react gaat hier aardig op z'n bek

[ Voor 24% gewijzigd door Verwijderd op 01-11-2003 00:36 ]

[jep]

Die =(') errors heb ik niet op een andere bak die 't ook niet doet. De NFS servers die ik gebruik zijn debian machines, redhat machines en windows machines (Dell powervaults), maar alle debian clients hebben dit.

Het lijkt dus aan de client te liggen, maar waarom.... is mij nog onduidelijk

[Bergen]

De originele melding is tar: Removing leading `/' from member names maar React maakt daar zo'n mooie code van. Die melding is verder niets bijzonders.

Ik heb even zitten Googlen en er zijn wel meer mensen met die "Wrote only 0 of 10240 bytes"-melding, maar die hebben allemaal een tapedrive. Het zou iets te maken kunnen hebben met blocksizes (die je met mount instelt). Ook las ik nog een vaag verhaal dat je de stream uit tar niet zomaar over het netwerk kunt sturen. In dat geval zou je de tar dus eerst lokaal moeten aanmaken en daarna naar de backupserver moeten sturen. Maarja, da's eigenlijk ook een stream toch? Nouja misschien werkt het...

[ Voor 17% gewijzigd door Bergen op 01-11-2003 05:08 ]

[Verwijderd]

Permissie problemen? Eventueel zouden het nog linux nfs bugs kunnen zijn.

[jep]

Die tar over 't netwerk naar een NFS volume jagen doe ik al jaren op RedHat systemen. Pas sindskort ben ik ook bij een bedrijf waar ik 't beheer doe op Debian over gegaan en loop ik tegen dit probleem aan. Ik durf echter niet met zekerheid te zeggen of dit een kernel of een debian issue is, aangezien die RedHat machines nog op iets oudere kernels lopen.

Een permission probleem lijkt me niet het geval, ik was nog vergeten te zeggen dat ik in dit geval wel tot 3.1 Gigabyte kom!

[jep]

Iemand nog enig idee? Ik kan me overigens niet voorstellen dat het een debian bug is. Dan zou er toch wel informatie over beschikbaar zijn?

[MikeN]

Volgens wat linkjes hier en daar lijkt dit echt te maken te hebben met de blocksize (zoals
GerbenW ook al aangeeft). Zeker aangezien de Linux NFS implementatie niet echt perfect is, zou je kunnen kijken of het meegeven van een andere blocksize aan tar helpt. Probeer anders tar eens te starten met -b10 erbij, misschien dat dat helpt.
Overigens is kicken binnen 24 uur eigenlijk not done hè

[jep]

Ik heb wat nachten over geslagen en mijn bioritme ligt ernstig op zijn gat . Excuus Ik ga het even proberen.

[jep]

Niet geheel onlogisch:

code:

shell:~# tar -b10 -cf /backups/shell/home.tar /home/
tar: Removing leading `/' from member names
tar: /backups/shell/home.tar: Wrote only 0 of 5120 bytes
tar: Error is not recoverable: exiting now

[MikeN]

jep schreef op 02 november 2003 @ 00:33:
Ik heb wat nachten over geslagen en mijn bioritme ligt ernstig op zijn gat .

jep schreef op 02 november 2003 @ 00:41:
Niet geheel onlogisch:

code:

shell:~# tar -b10 -cf /backups/shell/home.tar /home/
tar: Removing leading `/' from member names
tar: /backups/shell/home.tar: Wrote only 0 of 5120 bytes
tar: Error is not recoverable: exiting now

Mja, er verandert niets dus. [wilde gok mode aan]Het lijkt erop dat hij iets niet kan wegschrijven, misschien staat hierover iets in de syslogs?[/]

Vaag probleem. (* MikeN heeft zelf wel eens getarred over NFS (Debian naar Gentoo, beide met recente 2.4) en dat ging gewoon goed... Ging daarbij wel om minder data (± 1 GB))

[jep]

Helemaal niets in de logfiles, op geen enkele server. Ik wil wel een debian package droppen door bijvoorbeeld zelf iets te compilen, maar dan is 't nog de vraag of het tar, nfs-common, de kernel of wat anders is.

[MikeN]

Mja, om daarachter te komen zou ik strace er maar even op loslaten, dan kun je iig zien wat hij doet op het moment dat hij eruit klapt, en dus zien of het een kernel of tar probleem is.

[jep]

code:

write(3, "\377\377\377\377\377\377\377\377\377\377\377\377\377\377"..., 5120) = -1 ESTALE (Stale NFS file handle)
write(2, "tar: ", 5tar: )                    = 5
write(2, "/backups/shell/home.tar: Wrote o"..., 51/backups/shell/home.tar: Wrote only 0 of 5120 bytes) = 51
write(2, "\n", 1
)                       = 1
write(2, "tar: ", 5tar: )                    = 5
write(2, "Error is not recoverable: exitin"..., 37Error is not recoverable: exiting now) = 37
write(2, "\n", 1
)                       = 1
_exit(2)                                = ?
shell:~#

[MikeN]

Dit is echt heel vaag.

quote: http://www.iihe.ac.be/local/info.sun-managers/msg00039.html

ESTALE 70 Stale NFS file handle
An NFS client referenced a file that it had opened but
that had since been deleted.

Dit zou betekenen dat het bestand op de server is verwijderd, wat mij niet lijkt. Lijkt me dus toch een bug in de kernel, waarbij het updaten van de server of de client anar de laatste 2.4.x kernel zou kunnen helpen. De server lijkt het meest logische punt voor een upgrade, aangezien _daar_ de ESTALE error in principe vandaan hoort te komen.

[jep]

Op mijn eigen dozen (Waarop ik dit alles test) draait 2.4.22, eergisteren gebakken.

[MikeN]

Ok, hier houdt het voor mij ook op dan
Misschien dat een user hier, of anders iemand op de linux-net mailinglist er meer over weet?