On Sun, 17 Jun 2012 15:07:43 +0000, Tim Bannister wrote: > > On Sat, Jun 16, 2012 at 11:49:55AM +0000, Tim Bannister wrote: > > > > In summary, I think NILFS is fantastic in short bursts of heavy pressure > > > > so long as space isn't exhausted. > > > > > OK, but if exhausting the space leads to unrecoverable / difficult-to-fix > > > data loss then it's a poor choice of filesystem for uses where a full > > > filesystem is unlikely but remains a possibility (eg a mail spool). If > > > /var/tmp shouldn't be on NILFS then probably /var shouldn't be on NILFS > > > either. > … > > Perhaps one area where NILFS could be improved is in handling of disk full > > errors, for example, not allowing complete exhaustion of space unless a > > cleaner is running. > > Lots of filesystems reserve a certain amount of space for root. I would extend > this for NILFS2 to reserve some space for the cleaner daemon (perhaps with > an ioctl that can be used by the daemon to bypass the restriction). NILFS2 already has the reserved space for cleaner daemon, so it works at disk full. The problem seems that the kernel code of NILFS2 returns a disk full error to userland programs even if the volume has room for making free space with GC. Well-behaved filesystem should not do so. I think this is one of drawbacks of the current NILFS2 design. However, waiting for disk cleanup would be so costly without efficient GC algorithm. Actually, I feel improvement of the GC algorithm is a priority issue for production use. Regards, Ryusuke Konishi > Easier said than coded ;-) > > -- > Tim Bannister > IT Services > The University of Manchester > > e: Tim.Bannister@xxxxxxxxxxxxxxxx-- > To unsubscribe from this list: send the line "unsubscribe linux-nilfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html ��.n��������+%������w��{.n�����{��x�~���n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
