Date: Sat, 7 Jan 2012 18:14:56 -0600 From: Adam Vande More <amvandemore@gmail.com> To: Benjamin Kaduk <kaduk@mit.edu> Cc: doc@freebsd.org Subject: Re: Suggestion for Handbook Message-ID: <CA%2BtpaK0Okn-M2GSY7rf_VWj-yB-VoP8eg_Lyqg41etuKL9ci0w@mail.gmail.com> In-Reply-To: <alpine.GSO.1.10.1201070015390.882@multics.mit.edu> References: <CA%2BtpaK3icCaP_uOJTC8R2mCoK0gcoxfm%2BVyrsYbc0iUFL2V-iQ@mail.gmail.com> <alpine.GSO.1.10.1201070015390.882@multics.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 6, 2012 at 11:17 PM, Benjamin Kaduk <kaduk@mit.edu> wrote: > I think dd would be preferred precisely because it does not use sparse > files -- all blocks for the image will be allocated. > > If a sparse file was used, and the physical disk became close to full, > then when the system goes to make a write to the image and the backing file > cannot be grown, things are unlikely to fail gracefully. > A full image imposes other penalties and drawbacks. If you use a modern hypervisor, it's default backing store will be some type of glorified sparse file(vmdk, vdi, qcow2 -- at least AFAIK on qcow2). I would venture to guess that is because those communities are aware of the advantages and disadvantages of each with sparse files chosen consistently as the default. Furthermore, this is the error you get when writing to an overcommited sparse file: No space left on device galacticdominator# diskinfo /dev/md0 /dev/md0 512 1073741824000 2097152000 0 0 galacticdominator# diskinfo /dev/zvol/zoot/usr/home/zvol-test /dev/zvol/zoot/usr/home/zvol-test 512 5242880 10240 0 0 So it seems a sysadmin ought to be able to deal with that. -- Adam Vande More
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BtpaK0Okn-M2GSY7rf_VWj-yB-VoP8eg_Lyqg41etuKL9ci0w>