I have a script which generates a file and then immediately uses ''du -h'' to obtain its size. With Solaris 10 I notice that this often returns an incorrect value of ''0'' as if ZFS is lazy about reporting actual disk use. Meanwhile, ''ls -l'' does report the correct size. Bob =====================================Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
It may not be relevant, but I''ve seen ZFS add weird delays to things too. I deleted a file to free up space, but when I checked no more space was reported. A second or two later the space appeared. And I''m also seeing zpool status report that drives are ok when one is disconnected. I have to run it a second time to correctly show that one is now unavailable. They may not be related, but the end result is pretty similar - there''s a noticable delay before ZFS gives you the correct, up to date information. This message posted from opensolaris.org
Bob Friesenhahn wrote:> I have a script which generates a file and then immediately uses ''du > -h'' to obtain its size. With Solaris 10 I notice that this often > returns an incorrect value of ''0'' as if ZFS is lazy about reporting > actual disk use. Meanwhile, ''ls -l'' does report the correct size. >"ls -l" shows the length. "ls -s" shows the size, which may be different than the length. You probably want size rather than du. -- richard
On Feb 16, 2008, at 06:43, Ross wrote:> It may not be relevant, but I''ve seen ZFS add weird delays to > things too. I deleted a file to free up space, but when I checked > no more space was reported. A second or two later the space appeared.This also happens on FreeBSD''s UFS if you have SoftUpdates enabled. I forget exactly how it works (see McKusick''s paper), but basically there is a slight delay in updating the meta-data on disk, which gives the system some time to coalesce several operations in memory before doing any disk I/O. It makes it very easy to do an ''rm -rf'' on several hundred megabytes, which returns to the command line almost immediately; it''s several seconds before you hear any disk thrashing.
On Sat, 16 Feb 2008, Richard Elling wrote:> "ls -l" shows the length. "ls -s" shows the size, which may be > different than the length. You probably want size rather than du.That is true. Unfortunately ''ls -s'' displays in units of disk blocks and does not also consider the ''h'' option in order to provide a value suitable for humans. Bob =====================================Bob Friesenhahn bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
> On Sat, 16 Feb 2008, Richard Elling wrote: > > > "ls -l" shows the length. "ls -s" shows the size, > which may be > > different than the length. You probably want size > rather than du. > > That is true. Unfortunately ''ls -s'' displays in > units of disk blocks > and does not also consider the ''h'' option in order to > provide a value > suitable for humans. > > BobISTR someone already proposing to make ls -h -s work in a way one might hope for. This message posted from opensolaris.org
myxiplx at hotmail.com said:> It may not be relevant, but I''ve seen ZFS add weird delays to things too. I > deleted a file to free up space, but when I checked no more space was > reported. A second or two later the space appeared.Run the "sync" command before you do the "du". That flushes the ARC and/or ZIL out to disk, after which you''ll get accurate results. I do the same when timing how long it takes to create a file -- time the file creation plus the sync to see how long it takes to get the data to nonvolatile storage. Regards, Marion
On Tue, Feb 19, 2008 at 12:13:25PM -0800, Marion Hakanson wrote:> myxiplx at hotmail.com said: > > It may not be relevant, but I''ve seen ZFS add weird delays to things too. I > > deleted a file to free up space, but when I checked no more space was > > reported. A second or two later the space appeared. > > Run the "sync" command before you do the "du". That flushes the ARC and/or > ZIL out to disk, after which you''ll get accurate results. I do the same when > timing how long it takes to create a file -- time the file creation plus the > sync to see how long it takes to get the data to nonvolatile storage.When logging was first added to UFS, it had the same issue. But I believe statvfs was modified to take future removes (logged) into account. Can ZFS do the same? -- Darren Dunham ddunham at taos.com Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. >