One week old build... # df -i . Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on ram01/mnt1 239465344 239465344 0 100% 13163 0 100% /mnt1 # ls -aliT zero 20797 -rw-r--r-- 1 user user 43515904 Jul 28 23:20:57 2009 zero # rm -f zero rm: zero: No space left on device # :> zero cannot create zero: File exists # cp /dev/null zero overwrite zero? (y/n [n]) y # ls -aliT zero 20797 -rw-rw-rw- 1 root wheel 0 Jul 28 23:25:17 2009 zero # rm -f zero [gone]
Try truncating some files. -Kip On Tue, Jul 28, 2009 at 8:29 PM, grarpamp<grarpamp@gmail.com> wrote:> One week old build... > > # df -i . > Filesystem ? 1K-blocks ? ? ?Used Avail Capacity iused ifree %iused ?Mounted on > ram01/mnt1 239465344 239465344 ? ? 0 ? 100% ? 13163 ? ? 0 ?100% ? /mnt1 > # ls -aliT zero > 20797 -rw-r--r-- ?1 user user ?43515904 Jul 28 23:20:57 2009 zero > # rm -f zero > rm: zero: No space left on device > # :> zero > cannot create zero: File exists > # cp /dev/null zero > overwrite zero? (y/n [n]) y > # ls -aliT zero > 20797 -rw-rw-rw- ?1 root ?wheel ?0 Jul 28 23:25:17 2009 zero > # rm -f zero > [gone] > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >-- When bad men combine, the good must associate; else they will fall one by one, an unpitied sacrifice in a contemptible struggle. Edmund Burke
On Wed, 29 Jul 2009 05:29:27 +0200, grarpamp <grarpamp@gmail.com> wrote:> One week old build... > > # df -i . > Filesystem 1K-blocks Used Avail Capacity iused ifree %iused > Mounted on > ram01/mnt1 239465344 239465344 0 100% 13163 0 100% /mnt1 > # ls -aliT zero > 20797 -rw-r--r-- 1 user user 43515904 Jul 28 23:20:57 2009 zero > # rm -f zero > rm: zero: No space left on device > # :> zero > cannot create zero: File exists > # cp /dev/null zero > overwrite zero? (y/n [n]) y > # ls -aliT zero > 20797 -rw-rw-rw- 1 root wheel 0 Jul 28 23:25:17 2009 zero > # rm -f zero > [gone]Do you have everything linked in a snapshot? Ronald.
2009/7/29 grarpamp <grarpamp@gmail.com>:> One week old build... > > # df -i . > Filesystem ? 1K-blocks ? ? ?Used Avail Capacity iused ifree %iused ?Mounted on > ram01/mnt1 239465344 239465344 ? ? 0 ? 100% ? 13163 ? ? 0 ?100% ? /mnt1 > # ls -aliT zero > 20797 -rw-r--r-- ?1 user user ?43515904 Jul 28 23:20:57 2009 zero > # rm -f zero > rm: zero: No space left on device > # :> zero > cannot create zero: File exists > # cp /dev/null zero > overwrite zero? (y/n [n]) y > # ls -aliT zero > 20797 -rw-rw-rw- ?1 root ?wheel ?0 Jul 28 23:25:17 2009 zero > # rm -f zero > [gone]this is a known problem with the current version of ZFS. Due to the way ZFS handles access to the data it stores, even a rm causes a write, which requires some additional disk space in the beginning: Instead of simply unlinking what should be removed ZFS creates another tree without the removed data. Only if this new tree has been entirely written to disk the old information is removed. This is a rather rough explanation and probably not entirely correct, but I hope it suffices. Only hope: Make sure that not all disk space is used. Christian
Christian Walther wrote:> 2009/7/29 grarpamp <grarpamp@gmail.com>: > >> One week old build... >> >> # df -i . >> Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on >> ram01/mnt1 239465344 239465344 0 100% 13163 0 100% /mnt1 >> # ls -aliT zero >> 20797 -rw-r--r-- 1 user user 43515904 Jul 28 23:20:57 2009 zero >> # rm -f zero >> rm: zero: No space left on device >> # :> zero >> cannot create zero: File exists >> # cp /dev/null zero >> overwrite zero? (y/n [n]) y >> # ls -aliT zero >> 20797 -rw-rw-rw- 1 root wheel 0 Jul 28 23:25:17 2009 zero >> # rm -f zero >> [gone] >> > > > this is a known problem with the current version of ZFS. Due to the > way ZFS handles access to the data it stores, even a rm causes a > write, which requires some additional disk space in the beginning: > Instead of simply unlinking what should be removed ZFS creates another > tree without the removed data. Only if this new tree has been entirely > written to disk the old information is removed. This is a rather rough > explanation and probably not entirely correct, but I hope it suffices. > Only hope: Make sure that not all disk space is used. > > Christian >Indeed, if by some coincident (like a growing logfile) every single byte is used, even the copy action might fail... To prevent this you could set the maximum size of all partitions in your pool so that the sum of them is smaller then the size of your pool. Just a thought. Greetz, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20090729/7810b918/signature.pgp
Yep, the cp /dev/null <file> works to truncate. So I can deal with it. Yep, everything is snapshotted. Yep, this is a Sun issue not a FreeBSD one. FreeBSD should just stay current with the versions and the minimum needed to port... fbsd dev time is valuable elsewhere. I do remember reading about copy on write, d-oh :) ZFS should probably keep track of the largest extent needed to effect any given operation and reserve that behind the scenes. If it took n bytes to create something sans data, it'll probably take n bytes to modify it. Quotas and things might work though the user under quota might run into the same problem. Who knows. Thx CW, et al.