From owner-freebsd-questions@FreeBSD.ORG Sat Mar 6 02:40:02 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE30E1065674 for ; Sat, 6 Mar 2010 02:40:02 +0000 (UTC) (envelope-from fbsd1@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id C95AF8FC0C for ; Sat, 6 Mar 2010 02:40:02 +0000 (UTC) Received: from [10.0.10.3] ([202.69.174.43]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Mar 2010 18:40:02 -0800 Message-ID: <4B91C07D.7090503@a1poweruser.com> Date: Sat, 06 Mar 2010 10:39:57 +0800 From: Fbsd1 User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: spellberg_robert References: <4B9038B0.9050401@emailrob.com> In-Reply-To: <4B9038B0.9050401@emailrob.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Mar 2010 02:40:02.0800 (UTC) FILETIME=[5294FF00:01CABCD6] X-Sender: fbsd1@a1poweruser.com Cc: fbsd_questions Subject: Re: [ fbsd_questions ] tar(1) vs. msdos_fs: a death_spiral ? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2010 02:40:03 -0000 spellberg_robert wrote: > greetings, all --- > > i confess that this one has me flummoxed. > the short question: does tar(1) spit_up when extracting onto an > msdos_fs hard_drive ? > > [ i tried the mailing_list archives "tar AND msdos", for -questions, > -chat, -bugs, -newbies, -performance ] > [ other research as indicated ] > > > > i have no problem using tar(1) on ufs. > large files, small files; if i am on ufs, everything is fine. > > i have been creating tarballs from medium_size msdos_fs drives, also. > this worked fine. > i would check them by extracting into a ufs root_point. > no problem. > > this week, i tried to do something new. > i wanted to take a tarball, already on ufs, that was created from an > msdos_fs drive and > extract it onto an msdos_fs drive. > this, to me, actually seems like a reaasonable idea; but, what do i know ? > > well, it starts out just fine, but, it rapidly degenerates into what is, > normally, infinite_loop land. > when ps(1) says cpu_% of 1%, 2%, 5%; ok, it is an active process. > in about ten minutes, tar(1) enters 90% cpu. > after 20 minutes, 99%. > > i does not matter if X_windows is running. > foreground or background process, no difference. > > it seems to be working correctly because the error_file is always of > zero_size. > i suspect that if i left it alone, after a few days, it would finish. > > > > some details > [ everything is ufs, using 8kB/1kB, except "/mnt", which is clustered > as indicated; > of course, the tarball is not named "ball", > nor is the path, to the tarball, named "path", but, then, you knew that > ]. > > > mkdir /path_c > mkdir /path_c/88_x > > mkdir /path_d > mkdir /path_d/88_x > > > mount -v -t msdos /dev/ad1s1 /mnt [ fat_32, about > 6_GB, 4_KB cluster, the "c:\" drive, primary partition. ] > cd /mnt > ( tar cvplf /path_c/99_ball.tar . > > /path_c/90_cvpl.out ) > > & /path_c/91_cvpl.err & [ real time 16m 07s, > exit_status 0 ] > cd / ; umount /mnt > > > mount -v -t msdos /dev/ad1s5 /mnt [ fat_32, about > 12_GB, 8_KB cluster, the "d:\" drive, extended partition. ] > cd /mnt > ( tar cvplf /path_d/99_ball.tar . > > /path_d/90_cvpl.out ) > > & /path_d/91_cvpl.err & [ real time 20m 15s, > exit_status 0 ] > cd / ; umount /mnt > > > cd /path_c/88_x > ( tar xvplf ../99_ball.tar > > ../92_xvpl.out ) > > & ../93_xvpl.err & [ real time 08m 11s; > exit_status 0 ] > diff ../9[02]* [ exit_status 0; the > tables_of_contents are the same ] > ls -l .. [ visually inspect > the error_files to be of zero_size - verified ] > > > cd /path_d/88_x > ( tar xvplf ../99_ball.tar > > ../92_xvpl.out ) > > & ../93_xvpl.err & [ real time 12m 37s; > exit_status 0 ] > diff ../9[02]* [ exit_status 0; the > tables_of_contents are the same ] > ls -l .. [ visually inspect > the error_files to be of zero_size - verified ] > > > [ note that this approach works; it is a good excuse to refill my > coffee_cup. ] > > > [ physically replace the source hard_drive w/ 80_GB capacity, 32_KB > cluster, primary_partition only, virgin hard_drive. > this destination hard_drive was "fdisk"ed and "format"ed > yesterday_morning; > this drive was "scandisk"ed yesterday for 12 hours, using the > "thorough" option, > it has zero bad clusters [ i wanted to eliminate the drive as the > problem ] > ]. > > > mount -v -t msdos /dev/ad1s1 /mnt > > mkdir /mnt/path_cc > cd /mnt/path_cc > > ( tar xvplf /path_c/99_ball.tar > > ../92_xvpl.out ) > > & ../93_xvpl.err & [ started this at > 18:05_utc, it is now about 21:35_utc; > the toc_file, from > the 8_minute extraction above, has 87517 lines in it; > the current > toc_file has only 12667 lines. > ] > > [ this is the second hard_drive i have tried this on, this week; > i will probably kill the process as xterm is being updated about 8 > seconds apart, now. > ] > > > on the first hard_drive [ i have not done this on the second drive, yet ] > i noted that i had a successful extraction on the ufs drive. > not being the smartest person around, i had, what i thought to be, a > --brilliant-- idea, > "what if i try a recursive copy of the successful extraction" ? > > this is interesting; > the recursive copy started_out like gang_busters, then, just like the > extraction, slowly bogged_down to 99%_cpu. > > hmmm..., two different msdos_fs hard_drives, two different > normally_reliable utilities, same progressive_hogging of the cpu. > this makes me wonder about the msdos_fs hard_drive, which is, rapidly, > becoming the only remaining common factor. > > > > ok. > i tried the mailing lists. > right now, i am web_page searching; > tar(1) seems to be slow in some situations, but, i have not, yet, > found --this-- situation. > also, in reading the man_pages for mount(1) and tar(1), i am starting to > wonder if this could be a tar(1) "block_size" issue. > > i am not doing any encryption or compression, in either direction. > last check at about 22:45_utc: 99.0%_cpu, 0.1%_mem. > > > > does anyone have any thoughts ? > > NO. I tar /usr/home/me to /c/backup where /c is a second hard drive with msdosfs on it. also do tar to /a where /a is a msdos floppy. In both cases the speed is always the same on the same PC. Now running tar on a 386 8mhz cpu versus a pentum/pro 2ghz cpu is night and day difference in speed.