Date: Fri, 1 Oct 2010 01:31:08 +0200 From: Markus Gebert <markus.gebert@hostpoint.ch> To: fbsd@dannysplace.net Cc: freebsd-fs@freebsd.org Subject: Re: Strange ZFS problem, filesystem claims to be full when clearly not full Message-ID: <8762A442-5027-48E4-B51F-73F29658CA2F@hostpoint.ch> In-Reply-To: <4CA50BF1.60503@dannysplace.net> References: <4CA45444.6070002@dannysplace.net> <201009301438.o8UEckoY019473@lurza.secnetix.de> <20100930144845.GA19926@icarus.home.lan> <4CA4B12B.7050307@icyb.net.ua> <AANLkTinHoxX4MfVCEB2rrdcS1ubwQp%2Bc37uP2BcP2Crm@mail.gmail.com> <AANLkTimsSpP4nCE18H%2BQJCS1iKqw-wmoUdCc1OdU1tM2@mail.gmail.com> <4CA50BF1.60503@dannysplace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01.10.2010, at 00:15, Danny Carroll wrote: >>=20 >> If the process causing this is gone, or is working correctly (seeing >> that the fs is no longer growing, I hope), >> can dead unlinked files still remain, is there a way to purge them? >=20 > I can't remember exactly what happens and it's probably different for > each flavour of unix and *nux. > If a file is deleted, then the directory entry for the inode is > de-linked. If it's the last link to that inode then usually that = inode > is freed. >=20 > But when a process holds a handle to a file when it's deleted, then = the > reclaim does not happen AFAIK until *after* the file handle is closed. >=20 > <speculation> > I wonder what happens when, if a file handle is opened for writing, > someone else comes along and truncates the file. =20 > Perhaps a the seek position of the open handle is reset to 0, or = perhaps > (not likely) a write operation after truncation would result in an = error. > </speculation> AFAIK the file handle offset won't get reset to anything unless O_APPEND = was used to open the file (maybe there are other special cases). In = either case, the write will _not_ fail due to an offset beyond EOF, = instead a hole is created and the new data gets written after that. (see = man lseek(2)) The hole won't use disk space (as shown by df or zfs list), but is = considered part of the file size (as shown by ls). In other words, = truncating might free disk space, no matter what offsets other = filehandles have. However I don't see the point here. If the OP knows the file, he may as = well delete it to free disk space. If he doesn't, or it's inaccessible = (deleted but referenced), truncating isn't an option. Markus
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8762A442-5027-48E4-B51F-73F29658CA2F>