[ fbsd_questions ] tar(1) vs. msdos_fs: a death_spiral ?

Fbsd1 fbsd1 at a1poweruser.com
Sat Mar 6 02:40:03 UTC 2010


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.






More information about the freebsd-questions mailing list