From owner-freebsd-hackers Sun Oct 29 22:31:22 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from ns.internet.dk (ns.internet.dk [194.19.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 2F18E37B479 for ; Sun, 29 Oct 2000 22:31:18 -0800 (PST) Received: (from uucp@localhost) by ns.internet.dk (8.11.1/8.11.1) with UUCP id e9U6UtN19735; Mon, 30 Oct 2000 07:30:55 +0100 (CET) (envelope-from leifn@neland.dk) Received: from gina (gina.neland.dk [192.168.0.14]) by arnold.neland.dk (8.11.0/8.11.0) with SMTP id e9U61TZ35278; Mon, 30 Oct 2000 07:01:30 +0100 (CET) (envelope-from leifn@neland.dk) Message-ID: <01a801c04236$ed0a0d20$0e00a8c0@neland.dk> Reply-To: "Leif Neland" From: "Leif Neland" To: "Ryan Thompson" , "Matt Dillon" Cc: References: Subject: Re: Filesystem holes Date: Mon, 30 Oct 2000 07:00:55 +0100 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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