For Programmers: Free Programming Magazines  


Home > Archive > Unix Programming > March 2005 > Will sparse files help in deleting the initial part of an Accounting file?









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Will sparse files help in deleting the initial part of an Accounting file?
mshetty@mail.com

2005-03-17, 3:59 pm

Hi,

I am reading the accounting file /var/adm/pacct through a program of
mine. After I read some no. of records I want to delete whatever I read
so far. I have the position until where I have read. I cannot however
use the standard method of copying the file because the accounting file
could be growing in size while I am copying. I do not want to stop
accounting file prior to copy as doing so would prevent data of process
terminated in this period from being collected by the Accounting.

Would sparse files help in this scenario? Is the accounting file a
sparse file? Would help if I could get some clue on how this can be
done.

Tried truncate, ftruncate, FREESP but of no help..

Thanks and Regards,
M Shetty

Pascal Bourguignon

2005-03-17, 3:59 pm

mshetty@mail.com writes:

> Hi,
>
> I am reading the accounting file /var/adm/pacct through a program of
> mine. After I read some no. of records I want to delete whatever I read
> so far. I have the position until where I have read. I cannot however
> use the standard method of copying the file because the accounting file
> could be growing in size while I am copying. I do not want to stop
> accounting file prior to copy as doing so would prevent data of process
> terminated in this period from being collected by the Accounting.
>
> Would sparse files help in this scenario? Is the accounting file a
> sparse file? Would help if I could get some clue on how this can be
> done.
>
> Tried truncate, ftruncate, FREESP but of no help..


Once a block has been allocated to a file, it cannot be removed.

You can make a file sparse by moving farther than the EOF and writting
a byte. Then full blocks between the old EOF and the new byte won't
be allocated and will be read as null. But once a block is allocated,
even if entirely null, it cannot be removed.

You'd have to create a new file, and copy data. Not what you want...


You could rotate the accounting file and restart accounting to make it
go to the new file. See logrotate(8).

--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
Kurtis D. Rader

2005-03-17, 8:57 pm

On Thu, 17 Mar 2005 04:55:21 -0800, mshetty wrote:

> I am reading the accounting file /var/adm/pacct through a program of
> mine. After I read some no. of records I want to delete whatever I read
> so far. I have the position until where I have read. I cannot however
> use the standard method of copying the file because the accounting file
> could be growing in size while I am copying. I do not want to stop
> accounting file prior to copy as doing so would prevent data of process
> terminated in this period from being collected by the Accounting.
>
> Would sparse files help in this scenario? Is the accounting file a
> sparse file? Would help if I could get some clue on how this can be
> done.


You're going about it the wrong way. The solution is to rename the
existing file and tell the kernel to start logging to a new file:

mv /var/account/pacct /var/account/pacct.1
touch /var/account/pacct
accton /var/account/pacct

The kernel will continue writing accounting records to pacct.1 (it holds a
reference to the inode) until you run the accton command to tell it to
begin logging to the new file. So no data will be lost.
junky_fellow@yahoo.co.in

2005-03-18, 8:57 am


Pascal Bourguignon wrote:
> mshetty@mail.com writes:
>
of[color=darkred]
read[color=darkred]
however[color=darkred]
file[color=darkred]
process[color=darkred]
>
> Once a block has been allocated to a file, it cannot be removed.

<snip>
You say that once a block is allocated to file, it cannot be removed.
I opened a text file in vi editor, and deleted some the lines from it.
After that, when I saw the size and total block allocated, the size was
reduced and total blocks allocted were also reduced.
Then I checked the inode number it was the same. How could this be
possible.

Andrei Voropaev

2005-03-18, 8:57 am

On 2005-03-18, junky_fellow@yahoo.co.in <junky_fellow@yahoo.co.in> wrote:
>
> Pascal Bourguignon wrote:

[...]
><snip>
> You say that once a block is allocated to file, it cannot be removed.
> I opened a text file in vi editor, and deleted some the lines from it.
> After that, when I saw the size and total block allocated, the size was
> reduced and total blocks allocted were also reduced.
> Then I checked the inode number it was the same. How could this be
> possible.
>


The editor simply truncated file to size zero and then wrote new
content. So inode stays the same but the size of the file (including
block count) is changed.


--
Minds, like parachutes, function best when open
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2010 codecomments.com