Scott, Thanks. It turns out this is a hard drive problem and the read is failing at that point in the file.
Which is very close to the 63.876 GBs mentioned here: http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.baseadmn/doc/baseadmndita/fs_jfs2.htm I used ddrescue to recover the file, but the tar file was unrecoverable from that point on. Dwight On Tue, Sep 8, 2009 at 4:41 AM, Scott Dowdle <[email protected]> wrote: > Dwight, > > According to the wikipedia file system comparison page > (http://en.wikipedia.org/wiki/Comparison_of_file_systems), JFS has a maximum > file size of 4 PiB. > > ----- "Dwight Schauer" <[email protected]> wrote: > >> Hello fellow OpenVZers, >> >> This is not really and OpenVZ situation perse, but an openvz patched >> kernel was involved. >> >> I tarred up a couple filesystems and piped the tar stream through ssh >> to a remote computer (hardware node running the OpenVZ patched 2.6.27 >> kernel) where I dd'ed it to a file. This a common backup method I've >> been using for a few years now if I'm going to wipe a system and >> start >> over. >> >> I'm using JFS on the arch linux based hardware node that was being >> copied to. >> >> The resulting file ended up being 137G (which is about right based on >> the source filesystem usage). >> >> du --human --total a4b4.tar >> 137G a4b4.tar >> 137G total >> >> However, I can only restore from 63G of the tar ball, so I attempted >> to see how much could be read. >> >> dd if=a4b4.tar of=/dev/null >> dd: reading `a4b4.tar': Input/output error >> 123166576+0 records in >> 123166576+0 records out >> 63061286912 bytes (63 GB) copied, 1193.69 s, 52.8 MB/s >> >> There were no critical files in that tar ball that are not kept >> elsewhere, that is not the issue. At this point I can consider what >> is >> past the 63G point in the tarball to unrecoverable, which is fine. >> >> I tried skipping the first 63GB, but that does not work. >> >> dd if=a4b4.tar skip=123166576 of=/dev/null >> dd: reading `a4b4.tar': Input/output error >> 0+0 records in >> 0+0 records out >> 0 bytes (0 B) copied, 27.2438 s, 0.0 kB/s >> >> It seems like it took a while to figure out that it could not perform >> this operation. >> >> Yeah, I know, I could have used bzip and made 2 separate files, I >> could have used rsync -av, I could have checked tarball before wiping >> the source files systems, etc, that is not the point here. Now that I >> know that JFS on my setup has a 63GB file size limit, I know now to >> accommodate for that in the future. >> >> I'm mainly just curious on how the system could write a larger file >> than it can read. >> >> Dwight >> _______________________________________________ >> Users mailing list >> [email protected] >> https://openvz.org/mailman/listinfo/users > > -- > Scott Dowdle > 704 Church Street > Belgrade, MT 59714 > (406)388-0827 [home] > (406)994-3931 [work] > _______________________________________________ > Users mailing list > [email protected] > https://openvz.org/mailman/listinfo/users > _______________________________________________ Users mailing list [email protected] https://openvz.org/mailman/listinfo/users
