[9fans] truncation via wstat on ken's fs

[9fans] truncation via wstat on ken's fs

[geoff]

Changing the length is easy, but giving back the no-longer-needed
blocks is messy, involving a recursive walk of the indirect blocks.
I'm tempted to just change the length, which gives the desired
user-visible effect, unless the side-effect of freeing the
unneeded storage is important to someone.

Re: [9fans] truncation via wstat on ken's fs

[Brantley Coile]

> Changing the length is easy, but giving back the no-longer-needed
> blocks is messy, involving a recursive walk of the indirect blocks.
> I'm tempted to just change the length, which gives the desired
> user-visible effect, unless the side-effect of freeing the
> unneeded storage is important to someone.

Leaving the blocks there was the first thing I thought of.
They will get reclaimed when the file is deleted anyway.
Seems like a good idea to me.

Re: [9fans] truncation via wstat on ken's fs

[Russ Cox]

> Changing the length is easy, but giving back the no-longer-needed
> blocks is messy, involving a recursive walk of the indirect blocks.
> I'm tempted to just change the length, which gives the desired
> user-visible effect, unless the side-effect of freeing the
> unneeded storage is important to someone.

I thought about this too, but it's not actually true.

It's important to free or zero the blocks:

fd = create("foo", ORDWR);
write(fd, "hello world", 12);
ftruncate(fd, 0);
pwrite(fd, "", 1, 11);

should result in a file with 12 zero bytes,
not the string "hello world\0".

It's not that hard to do the recursive walk.
Remove does it already.  In fossil we just pulled
that code out of remove and made it a separate
function that can be passed a length instead
of assuming 0.

Russ

Re: [9fans] truncation via wstat on ken's fs

[boyd, rounin]

> Changing the length is easy, but giving back the no-longer-needed
> blocks is messy, involving a recursive walk of the indirect blocks.

doesn't this fall out of the remove case?  i remember chris maltby
hacking 32V so that it would truncate to a point [unlink].

or, does remove do some other trickery?

Re: [9fans] truncation via wstat on ken's fs

[geoff]

Good point, Russ, and I had done something similar (cloned dtrunc()
and added a length argument).

Ken frees blocks in reverse order (last block freed first), presumably
to assist repairs if the system should crash in the middle of it, or
something of the sort.  The obvious way to truncate is to walk to the
point of truncation, zero any partial block after it, then free data
blocks (and if feasible indirect blocks) while walking to EOF.  Doing
this backward is a little messier.

Re: [9fans] truncation via wstat on ken's fs

[Charles Forsyth]

>>Ken frees blocks in reverse order (last block freed first), presumably
>>to assist repairs if the system should crash in the middle of it, or

it was traditional from v6:

/*
 * Free all the disk blocks associated
 * with the specified inode structure.
 * The blocks of the file are removed
 * in reverse order. This FILO
 * algorithm will tend to maintain
 * a contiguous free list much longer
 * than FIFO.
 */
itrunc(ip)
int *ip;
{
	...

Re: [9fans] truncation via wstat on ken's fs

[geoff]

I was just looking at that very comment.

It shouldn't matter for WORMs, since blocks are never reused.  I
wonder how much it matters for other file systems, given that one
would expect to be serving from RAM cache most of the time.  I note
that fossil seems to just free the blocks in forward order.

Re: [9fans] truncation via wstat on ken's fs

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

a bit further down in the same code is the real need for BSLOP:
some pesky `--' in the wrong place, but i digress.

even with the worm, it might depend how often files are created
and destroyed between dumps (eg, big mailboxes rewritten),
and meta-data writes are often forced through to the device i think.
it really depends how accurate the comment is, and whether it does
indeed make any detectable difference now!

[-- Attachment #2: Type: message/rfc822, Size: 2381 bytes --]

From: geoff@collyer.net
To: 9fans@cse.psu.edu
Subject: Re: [9fans] truncation via wstat on ken's fs
Date: Mon, 18 Oct 2004 01:24:04 -0700
Message-ID: <33b92a9c2d6b8da64f55409b1d7c1e76@collyer.net>

I was just looking at that very comment.

It shouldn't matter for WORMs, since blocks are never reused.  I
wonder how much it matters for other file systems, given that one
would expect to be serving from RAM cache most of the time.  I note
that fossil seems to just free the blocks in forward order.

Re: [9fans] truncation via wstat on ken's fs

[geoff]

As I recall, it didn't help enough on Unix; a busy system got its free
list scrambled pretty quickly, which was one of Berkeley's arguments
for bitmap allocation.

I'm inclined to free blocks in forward order for wstat truncation,
which ought to be far less common than truncation of existing files
via create, thus minimising any inefficiency.

Re: [9fans] truncation via wstat on ken's fs

[Aharon Robbins]

> > Changing the length is easy, but giving back the no-longer-needed
> > blocks is messy, involving a recursive walk of the indirect blocks.
> > I'm tempted to just change the length, which gives the desired
> > user-visible effect, unless the side-effect of freeing the
> > unneeded storage is important to someone.
>
> Leaving the blocks there was the first thing I thought of.
> They will get reclaimed when the file is deleted anyway.
> Seems like a good idea to me.

Who says the file will ever get deleted?

Arnold