Date: Fri, 28 May 1999 20:44:58 -0400 (EDT) From: Zhihui Zhang <zzhang@cs.binghamton.edu> To: "Christopher R. Bowman" <crb@ChrisBowman.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Algorithm used to delete part of a file Message-ID: <Pine.GSO.3.96.990528202945.11744A-100000@sol.cs.binghamton.edu> In-Reply-To: <199905282317.TAA11260@quark.ChrisBowman.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 28 May 1999, Christopher R. Bowman wrote: > It is difficult to understand if you are talking at the file system layer > (because you mention data and indirect blocks) or the application layer (you > mention looking at the vi code). At the file system layer you don't delete > blocks in the middle of a file. You can append to the file thus allocating new > data blocks (and perhaps indirect blocks if they are needed) that will be added > to the end of the file. Or you can truncate a file, thus freeing the data > blocks (and perhaps indirect blocks) at the end of the. When you truncate a > file the data blocks are returned to a list of free blocks, and when a block is > later reused for another purpose it is either written to in it's entirety or > zero filled, and then partially filed with your data (if you don't write the > entire block). In either case blocks are never added or removed except at the > end of the file, thus blocks never have to be "re-organized." They are simply > allocated or freed. If this is the level of your interest then looking at vi > source code won't help you. Thanks for your valuable information. This explains why I have not found any routines in the files under /ufs/ffs and /ufs/ufs that re-organize the on-disk image of a file in that way. If a middle part of a file is deleted, then all the remaining part of the file must be read by an editor (such as vi) and written out to another place before the file length is truncated. This algorithm seems to be not very efficient. But disk is not like memory, where we can simply modify pointers to point to new locations easily, I guess there may be no better way to do this. If you have any ideas about why this is not done by the filesystem itself, please let me know. Thanks for your help. Zhihui 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?Pine.GSO.3.96.990528202945.11744A-100000>