Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.mac.system > #57770
| From | Tom Stiller <clusterfux.upmon@gmail.com> |
|---|---|
| Newsgroups | comp.sys.mac.system |
| Subject | Re: Block vs file level copy |
| Date | 2014-03-09 13:08 +0000 |
| Organization | Old Men With Beards |
| Message-ID | <bo37dgFu0keU1@mid.individual.net> (permalink) |
| References | <lffu94$shm$1@dont-email.me> <BrOdnd-ItKeeGobOnZ2dnUVZ_oqdnZ2d@giganews.com> |
On 2014-03-08, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: > On 2014.03.08, 15:24 , Kir?ly wrote: >> We had a discussion a while back about the speed of a block level vs a >> file level copy of one volume to another. It's generally considered >> that a block-level copy is faster, but some argued that a file-level >> copy will be faster if the volume contains a lot of free space. There >> was more disagreement about whether a block-level copy copies that free >> space or not. I had the chance to test it over the last two days. >> >> I had a 2TB volume that was only 25% full (of Time Machine backups.) I >> wanted to copy it to a 3TB volume. >> >> Disk Utility's Restore function, which unmounts both the volumes and >> does a block-level copy, took 16 hours over FW800. >> >> SuperDuper, which leaves the volumes mounted and does a file-level copy, >> took 5 hours. >> >> That settled it for me. > > Useful. Thanks. > > Your data shows that block level is in fact faster (100%/16 hours = > 6.25% / hour) v. [25%/5 hours = 5%/hour]. So you'd want the source disk > to be at least 80% full to use Block rather than file. > > That's a bit rough, however - since another issue with file level > transfer is that the heads would be moving a lot more often, whereas > with block they would (in theory) only move cylinder to cylinder as needed. > > So I'd guesstimate that the breakeven point is somewhere around 50 - 60% > based on your numbers. Timing for file level copying is also strongly dependent on how many files are on the source device. Thousands of small files (as mignt be found on a startup volume) will slow down a file leved copy significantly, but have no effect on a block level copy. Note that TM backups do not include the many files that will be reconstituted or updated on startup.
Back to comp.sys.mac.system | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Block vs file level copy me@home.spamsucks.ca (Király) - 2014-03-08 20:24 +0000
Re: Block vs file level copy Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-03-08 16:09 -0500
Re: Block vs file level copy JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-03-08 16:33 -0500
Re: Block vs file level copy Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-03-08 23:01 +0000
Re: Block vs file level copy Oregonian Haruspex <bob_davis_retired@yahoo.com> - 2014-03-10 04:32 +0000
Re: Block vs file level copy Siri Cruz <chine.bleu@yahoo.com> - 2014-03-09 22:34 -0800
Re: Block vs file level copy Tom Stiller <clusterfux.upmon@gmail.com> - 2014-03-09 13:08 +0000
Re: Block vs file level copy Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-03-09 11:41 -0400
Re: Block vs file level copy Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-03-08 23:00 +0000
Re: Block vs file level copy billy@MIX.COM - 2014-03-08 23:48 +0000
Re: Block vs file level copy Martin Frost me at invalid stanford daht edu <nospam@stanford.edu.invalid> - 2014-03-08 22:14 -0700
Re: Block vs file level copy Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-03-09 07:20 +0000
Re: Block vs file level copy Siri Cruz <chine.bleu@yahoo.com> - 2014-03-09 22:55 -0800
Re: Block vs file level copy Siri Cruz <chine.bleu@yahoo.com> - 2014-03-09 22:11 -0800
csiph-web