On Fri, 29 Aug 2008 12:45:00 +0200, Jörn Engel wrote: > > The GC of NILFS depends on the userspace daemon to make policy decisions. > > NILFS cannot reclaim disk space on its own though it can work > > (i.e. read, write, or do other operations) without the daemon. > > After it runs out of free space, disk full errors will be returned > > until GC makes new space. > > This looks problematic. In logfs I was very careful to define a > "filesystem full" condition that is independent of GC. So with a single > writer, -ENOSPC always means the filesystem is full and the only way to > gain some free space is by deleting data again. > ... > > But, usually the GC will make enough disk space in the background > > before that occurs. > > Usually, yes. You just have to make sure that in the unusual cases the > filesystem continues to behave correctly. ;) As the side remark, the GC of nilfs runs in the background, not started after it runs out of free space. Basically the intended meaning of -ENOSPC is same; it does not mean the GC is ongoing, but means the deletion is required. Of course this depends on the condition that the GC has been working with enough speed, so the meaning is not assured strictly. But, at least I won't return -ENOSPC so easily, and will deal it more politely if needed. On the other hand, there are some differences in premise because nilfs is aiming at racking up past user data and makes it a top priority to keep data which is overwritten by recent updates. If users want to preserve much data in nilfs, it will increase the chance of disk fulls than regular file systems. Cheers, Ryusuke -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
