Date: Mon, 24 Jan 2011 17:52:19 +0100 From: Olivier Smedts <olivier@gid0.org> To: =?UTF-8?Q?=C5=A0imun_Mikecin?= <numisemis@gmail.com> Cc: freebsd-fs@freebsd.org Subject: Re: Write cache, is write cache, is write cache? Message-ID: <AANLkTi=Ym9FyDdwKk=v5XdWqeiFe7mqpFBi%2BH9VYX5cU@mail.gmail.com> In-Reply-To: <AANLkTi=SrEWnHxGLD-K1UZweJboEWuKysKr68L1rUSQ=@mail.gmail.com> References: <1ABA88EDF84B6472579216FE@Octa64> <20110122111045.GA59117@icarus.home.lan> <AANLkTik_rii-F_QWTP3OdyTS0gx1tDxv6--2LGGF6Ear@mail.gmail.com> <20110124144236.GA19500@icarus.home.lan> <AANLkTi=K0xYJciWgtzTkMP-BhnOOfc5UeUgX--sCVLma@mail.gmail.com> <AANLkTi=SrEWnHxGLD-K1UZweJboEWuKysKr68L1rUSQ=@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
2011/1/24 Olivier Smedts <olivier@gid0.org>: > 2011/1/24 Šimun Mikecin <numisemis@gmail.com>: >> 2011/1/24 Jeremy Chadwick <freebsd@jdc.parodius.com> >> >>> The term "flush" means many different things.  fsync(2), for example, >>> behaves differently on UFS than it does on ZFS.  People think that >>> "flush" means "guarantee the data written was written to disk", but >>> ensuring an actual ATA/SCSI command completes **and** has had its data >>> written to the platters is an entirely different beast (IMO) than "flush >>> kernel buffers to disk and hope for the best". >>> >> >> AFAIK, BIO_FLUSH should complete when data was written to disk (not before), >> or in the case of battery backed cache: when data was written to battery >> backed cache. >> AFAIK, ZFS doesn't only "flush kernel buffers" (like UFS does), but also >> executes BIO_FLUSH every X seconds (X=5 if my memory serves me well). So, >> you shouldn't loose data that was written before BIO_FLUSH executed. > > I thought ZFS also took care of executing BIO_FLUSH after each write > to ZIL, because every bit in ZFS expect writes to be ordered, and some > specific writes to be synced to platters, else your FS is gone if ZIL > is corrupted in some way. The way ZFS works is the reason there's *no* > fsck-like repair tool for it. Of course, this does not work if you > don't use a propre controller or disk, but it should behave that way > for most, no ? > >>  With single disks, all I've seen are read/write errors which can't be >> >>> repaired.  "zpool status" will actually show what files got affected as >>> a result of the issue, though sometimes "zpool scrub" needs to be run >>> before this can be detected. >> >> >> Adding redudancy does make your data safer, but if everything is working as >> explained, sudden power-loss shouldn't be the cause of those errors even >> with single disks. Correct me if you think that I'm mistaken. >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >> > > > > -- > Olivier Smedts                         _ >                     ASCII ribbon campaign ( ) > e-mail: olivier@gid0.org    - against HTML email & vCards X > www: http://www.gid0.org  - against proprietary attachments / \ > >  "Il y a seulement 10 sortes de gens dans le monde : >  ceux qui comprennent le binaire, >  et ceux qui ne le comprennent pas." > -- Olivier Smedts                         _                     ASCII ribbon campaign ( ) e-mail: olivier@gid0.org    - against HTML email & vCards X www: http://www.gid0.org  - against proprietary attachments / \  "Il y a seulement 10 sortes de gens dans le monde :  ceux qui comprennent le binaire,  et ceux qui ne le comprennent pas."help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=Ym9FyDdwKk=v5XdWqeiFe7mqpFBi%2BH9VYX5cU>