On Wed, Jun 25, 2008 at 01:31:55PM +0100, Dan Track wrote: > On Wed, Jun 25, 2008 at 12:48 PM, Chris G <cl@xxxxxxxx> wrote: > > On Wed, Jun 25, 2008 at 12:27:04PM +0100, Dan Track wrote: > >> Hi > >> > >> I've got a xen vm file called test, if I copy it with dd I get the following > >> dd if=/opt/xen/test of=/opt/test-vm.img bs=4096 > >> du -s /opt/xen/test = 1934112 > >> du -s /opt/test-vm.img = 26240040 > >> > >> My question is why is the test-vm.img larger in size than the original? > >> > > Perhaps because the original file is 'sparse', i.e. it has large > > unused chunks in it, when originally created these will be unallocated > > and use no space, only when written to will the space be allocated. > > However when you dd the file it writes everything (including 'nul' > > data) to the destination file. > > > Thanks for the heads up on this. If the data blocks don't have > anything written into them, then what data is written into them when > using dd? dd will write what is returned by the operating system when you read unused sections of a file, probably zeroes. > if I restore the dd image will the blocks then be in the > same state i.e unwritten to? No, you'll get a 'fully populated' file with the previously empty bits full of (probably) zeroes. It'll work fine though, or should do. > > Also following on from this if I create a file using dd let's say 2GB, > how does the filesystem know that all these blocks belong to the file > myfile.img, and where is the information stored to say that a block > has data written into it or not? It knows because dd explicity writes to every byte of the file, the information is in the filesystem directory structure (inodes, etc.). You get a file with unallocated 'holes' by opening a file, writing a bit of data at the start (maybe) and then doing a large seek forward in the file and writing some more data. The section you seek over (if it's large enough, presumably larger than the default allocation block size) will be empty and unwritten and will occupy no space on disk. -- Chris Green -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
