Re: FIFO files

[Carl-Daniel Hailfinger <c-d.hailfinger.kernel.2003@gmx.net>]

It might be more appropriate to continue discussing this at linux-fsdevel.

Ragnar Kjørstad wrote:
> On Wed, Jun 18, 2003 at 10:17:21AM +0400, Oleg Drokin wrote:
> 
>>Hello!
>>
>>On Tue, Jun 17, 2003 at 07:00:25PM +0200, Carl-Daniel Hailfinger wrote:
>>
>>>Yes, but if I understood Cyrille correctly, her/his(?) needs should be
>>>completely satisfied by sparse files.
>>>One process can append records at the end, and one other process can read
>>>records from the beginning of the file, marking the read data empty. The
>>
>>Hm, I am sorry, but this part is unclear.
>>I do not remember any API to create holes in existing files in place of already
>>present data.
> 
> 
> There isn't one.
> 
> XFS uses an ioctl to punch holes, dm_punch_hole, but it's prototype is
> specific to XDSM.
> 
> Once multiple filesystems implement the same functionality it makes sense 
> to have a common interface - maybe a new entry in struct
> inode_operations, and a corresponding systemcall?
> 
> Something like:
> int punch_hole(const char *path, off_t offset, size_t len);
> int fpunch_hole(int fd, off_t offset, size_t len);

make_hole or zap_range would be alternative names.


> The reader of the file would have to punch the holes after reading the
> data. IMHO punch_hole should not "move" the contents of the file, so the
> data is still available at the same offsets. If one rather would like
> the data to be available at the beginning of the file at all times
> something else is needed, maybe:
> 
> int truncate_start(const char *path, off_t offset);
> int ftruncate_start(int fd, off_t offset);
> 
> that truncates the beginning of the file, moving the data from pos
> offset to pos 0.
> 
> 
> But punch_hole is much more generic, and could be useful in cases like
> HSM and others. Basicly I think punch_hole is just something missing
> from the linux VFS - logically it should be there. It should be
> relatively easy to implement on all filesystems supporting sparse files,
> as the end result is the same.
> 
> Truncate_start is another beast. One some filesystems like ext2/3 it
> would not be possible to implement it effectively for large files, and
> there are problems with offsets that are not multiple of the blocksize.


Regards,
Carl-Daniel