|
From: Jeff G. <jg...@ma...> - 2002-07-20 00:47:56
|
Random thoughts on delayed allocation: * You want to reserve space via some sort of internal accounting, to properly handle ENOSPC * You probably want to either have a pool of pages, as a temporary backing store, or, grab an extra reference to the page passed to prepare/commit_write. For the second, I think you'll want to unlock the page ASAP, and lock it again later when you start doing I/O on it. * I think compression is better done outside the write path, to keep it simple and fast. Maybe something in ntfsprogs could talk to an ioctl(2) which compresses an open(2)'d file descriptor. The bigger advantage to delayed allocation is the allocation of contiguous runs. * FWIW the last close of a file triggers a flush, which might be a good point for actually allocating blocks * A lot of Unix tools do care about free space accounting, and in general, I think it makes a lot of people feel safer if its accurate Jeff |
