45 messages in org.freebsd.freebsd-fsRe: Areca vs. ZFS performance testing.| From | Sent On | Attachments |
|---|---|---|
| Jeremy Chadwick | Oct 30, 2008 8:31 pm | |
| Danny Carroll | Oct 30, 2008 9:07 pm | |
| Jeremy Chadwick | Oct 30, 2008 9:33 pm | |
| Andrew Snow | Oct 30, 2008 9:43 pm | |
| Danny Carroll | Oct 30, 2008 9:47 pm | |
| Danny Carroll | Oct 30, 2008 9:49 pm | |
| Danny Carroll | Oct 30, 2008 9:54 pm | |
| Simun Mikecin | Oct 31, 2008 2:20 am | |
| Simun Mikecin | Oct 31, 2008 4:56 am | |
| Peter Schuller | Nov 2, 2008 7:08 am | |
| Simun Mikecin | Nov 3, 2008 12:31 am | |
| Dieter | Nov 12, 2008 2:57 pm | |
| Danny Carroll | Nov 12, 2008 9:46 pm | |
| Jeremy Chadwick | Nov 12, 2008 11:42 pm | |
| Willem Jan Withagen | Nov 13, 2008 12:32 am | |
| Danny Carroll | Nov 13, 2008 3:09 am | |
| Danny Carroll | Nov 13, 2008 5:58 am | |
| Nikolay Denev | Nov 13, 2008 7:05 am | |
| Scott Long | Nov 13, 2008 8:49 am | |
| Danny Carroll | Nov 13, 2008 12:46 pm | |
| Danny Carroll | Nov 13, 2008 12:59 pm | |
| Eirik Øverby | Nov 16, 2008 12:26 pm | |
| Danny Carroll | Nov 16, 2008 7:15 pm | |
| Matt Simerson | Nov 16, 2008 10:06 pm | |
| Jeremy Chadwick | Nov 16, 2008 11:07 pm | |
| Wes Morgan | Nov 17, 2008 3:26 am | |
| Danny Carroll | Nov 17, 2008 3:42 am | |
| Matt Simerson | Nov 17, 2008 1:04 pm | |
| Matt Simerson | Nov 17, 2008 2:07 pm | |
| Danny Carroll | Nov 17, 2008 3:45 pm | |
| Jan Mikkelsen | Dec 2, 2008 2:38 am | |
| Wes Morgan | Dec 2, 2008 4:04 am | |
| Danny Carroll | Jan 7, 2009 4:33 pm | |
| Zaphod Beeblebrox | Jan 7, 2009 11:40 pm | |
| Koen Smits | Jan 7, 2009 11:48 pm | |
| Nikolay Denev | Jan 8, 2009 1:19 am | |
| Danny Carroll | Jan 8, 2009 6:29 pm | |
| Koen Smits | Jan 9, 2009 12:46 am | |
| Danny Carroll | Jan 9, 2009 1:02 am | |
| Koen Smits | Jan 9, 2009 7:57 am | |
| Andrew Snow | Jan 9, 2009 6:38 pm | |
| Danny Carroll | Jan 9, 2009 8:58 pm | |
| Danny Carroll | Jan 20, 2009 10:40 pm | |
| Koen Smits | Jan 21, 2009 1:15 am | |
| Danny Carroll | Jan 21, 2009 5:14 am |
| Subject: | Re: Areca vs. ZFS performance testing. | |
|---|---|---|
| From: | Simun Mikecin (numi...@yahoo.com) | |
| Date: | Nov 3, 2008 12:31:34 am | |
| List: | org.freebsd.freebsd-fs | |
Peter Schuller wrote:
In any case, why would the actual RAID controller cache be flushed, unless someone expliclitly configured it such? I would expect a regular BIO_FLUSH (that's all ZFS is going right?) to be satisfied by the data being contained in the controller cache, under the assumption that it is battery backed, and that the storage volume/controller has not been explicitly configured otherwise to not rely on the battery for persistence.
I'm using amr(4) driver with Dell PERC 4e/DC controller (which is a rebranded
LSI 320-2E) that has battery-backed cache and write-caching configured to be
write-back. This controller is connected to a LED light that shows when there is
something in the cache not yet commited to the disks.
Ever since I changed from UFS2 to ZFS that light comes off very quickly. It does
not stay on for longer periods of time (it did for upto 10 seconds when I used
UFS2 - it is a controller BIOS setting). So doing BIO_FLUSH in this case *does*
flush battery-backed cache.
I can restore old functionality by setting vfs.zfs.cache_flush_disable=1 but I
shouldn't use it in my case since the same system also has SATA disks with ZFS
on them and turning off BIO_FLUSH for SATA disks would be dangerous.
Please correct me if I'm wrong, but if synchronous writing to your RAID device results in actually waiting for underlying disks to commit the data to platters, that sounds like a driver/controller problem/policy issue rather than anything that should be fixed by tweaking ZFS.
AFAIK as I know BIO_FLUSH (which is for now implemeted only for ata(4) and
amr(4) - correct me if I'm mistaken) does just that: actually flushes and waits
for the cache content to be written on disk.
Or is it the case that ZFS does both a "regular" request to commit data (which I thought was the purpose of BIO_FLUSH, even though the "FLUSH" sounds more specific) and separately does a "flush any actual caches no matter what" type of request that ends up bypassing controller policy (because it is needed on stupid SATA drives or such)?
AFAIK BIO_FLUSH commits *everything* that is in the cache. It is needed for
stupid SATA drives. But I'm not so happy about it been turned on for amr(4)
flushing the entire 128MB battery backed cache.
_______________________________________________ free...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to "free...@freebsd.org"