Date: Mon, 30 Oct 2000 07:00:55 +0100 From: "Leif Neland" <leifn@neland.dk> To: "Ryan Thompson" <ryan@sasknow.com>, "Matt Dillon" <dillon@earth.backplane.com> Cc: <freebsd-hackers@FreeBSD.ORG> Subject: Re: Filesystem holes Message-ID: <01a801c04236$ed0a0d20$0e00a8c0@neland.dk> References: <Pine.BSF.4.21.0010291907320.27883-100000@ren.sasknow.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Hmm... Perhaps you're still missing my original point? I'm talking about > a file with 96GB in addressable bytes (well, probably a bunch of files, > given logical filesize limitations, but let's say for simplicity's sake > that we have a single file). It's actual "size" (in terms of allocated > blocks) will be only a bit larger than 2.1GB. (Directly proportional to > the used size of the dataset. Discrepancies only come into play when > record size != block size, but that can be worked around somewhat) > > In other words, ls -ls will report the "size" as some ridiculously large > number, will show a much smaller block count. So, assuming four records > are added to the file on block boundaries, the file will actually only use > four blocks... nowhere near 96GB! > > In the UNIX filesystem (ya, I know.. just pick one :-), size of file != > space allocated for file. Thus, my original questions were centered > around filesystem holes. I.e., non-allocated chunks in the middle of a > file. When trying to READ from within a hole, the kernel just sends back > a buffer of zeros... which is enough to show that the record is not > initialized. Actually, something like an "exists" function for a record > wouldn't touch the disk at all! When writing to a hole, the kernel simply > allocates the necessary block(s). This is really fast, too, for creation, > as the empty set can be written to disk with touch(1), and uses far less > memory than virtual initialization or memory structures ;-) > What will happen, if somebody (possibly you, as mahordomo says), tries to make a backup of that file. Will the copy also be with holes, or would that file suddenly use all 96GB? It will at least do so, if one does cat file>file.bak Probably tar will do the same. I'd be afraid to create something which could easily blow up by having normal operations applied to it. Leif To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01a801c04236$ed0a0d20$0e00a8c0>