<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.linux.file-systems.zfs.user">
    <title>gmane.linux.file-systems.zfs.user</title>
    <link>http://blog.gmane.org/gmane.linux.file-systems.zfs.user</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8481"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8480"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8479"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8478"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8477"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8476"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8475"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8474"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8473"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8472"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8471"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8470"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8469"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8468"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8467"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8466"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8465"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8464"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8463"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8462"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8481">
    <title>Re: can't get second ZFS pool to automount</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8481</link>
    <description>&lt;pre&gt;Hmm, looks correct to me. The drives are up before ZFS, so it should just
work. If you search through the archives, there might be more suggestions
about this. Sorry I couldn't be of more assistance.

t.


On Sat, May 18, 2013 at 1:50 PM, LosingMyZFS &amp;lt;losingmyzfs-Re5JQEeQqe8AvxtiuMwx3w&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:

&lt;/pre&gt;</description>
    <dc:creator>Tren Blackburn</dc:creator>
    <dc:date>2013-05-19T00:29:00</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8480">
    <title>Re: currupted pool [was: slow zfs]</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8480</link>
    <description>&lt;pre&gt;

This is also a known result of not having enough memory. The
other is crashes...


'Unexpected and possibly fatal' result I think it's said. Many have
reported crashes, some have reported corruption.


Good then. But most people who try this state of the art pice
of software, designed to run in multimillion dollar data centers,
for some reason try to do it on ancient piece of crap PC hardware.

Several of them so old it's 32bit!!



Thank you. Makes it a little better...


It wasn't, or I'm just so sick and tired of people not reading
the documentation properly and then bitch about all information
being there.

I'm not the best reader of documentation either, but when I get
a good kick in the behind (either after loosing data, getting 'strange
results' etc), I don't bitch about it...


It's possible that you actually have a bug there, but it will be
almost impossible to find because the hardware is ancient and not
suitable for the task. And even if it CAN be found, should it be
fixed - it DID occur on a machine without sufficient amount of
memory... 

There have been discussion on 'porting' (i.e. allowing older hardware
and/or less memory), but to date this have been rejected. And I for
one will keep voting no - hardware is cheap today!


&lt;/pre&gt;</description>
    <dc:creator>Turbo Fredriksson</dc:creator>
    <dc:date>2013-05-18T23:12:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8479">
    <title>currupted pool [was: slow zfs]</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8479</link>
    <description>&lt;pre&gt;
I wrote earlier, I don't wan't my data back. There is obviously a regression somewhere as it's 
corrupted now.


It's OK and I know about it. I understand it means it's supposed to be slow, not corrupted 
(definitely no crashes, no kernel panic).
And I _think_ it got currupted, there was some (~10-20) dirty reboot.


This system is 64 bit.


I understand this and I don't blame ZFS for the slowness.
Hopefully that wasn't the sense, what I wrote.


tamas

&lt;/pre&gt;</description>
    <dc:creator>Tamas Papp</dc:creator>
    <dc:date>2013-05-18T22:19:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8478">
    <title>Re: slow zfs</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8478</link>
    <description>&lt;pre&gt;


You have been warned - dedup requires a lot of memory. It's
everywhere in the documentation, and it is not a joke.

This is the way ZFS was _designed_. It's not just something
someone discovered and said 'oh, we should warn people about
this'. No, it was one of the core base design options.


Also, ZFS works really, really bad on a 32bit platform. This
is ALSO a design decision, and not a coincidence.

Buy modern hardware. It doesn't cost much to get a modern
mother board, enough memory and a CPU. If you can't afford
that, don't try to use top of the line software.
--
There are no dumb questions,
unless a customer is asking them.
- Unknown


&lt;/pre&gt;</description>
    <dc:creator>Turbo Fredriksson</dc:creator>
    <dc:date>2013-05-18T21:51:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8477">
    <title>Re: slow zfs</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8477</link>
    <description>&lt;pre&gt;
Nobody?

If that's the case, I just destroy the FS.

10x
tamas

&lt;/pre&gt;</description>
    <dc:creator>Tamas Papp</dc:creator>
    <dc:date>2013-05-18T21:42:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8476">
    <title>Re: Re: L2ARC Content</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8476</link>
    <description>&lt;pre&gt;
Guys, what does this all mean? Too much L2ARC is evil? If so, how much?

10x
tamas

&lt;/pre&gt;</description>
    <dc:creator>Tamas Papp</dc:creator>
    <dc:date>2013-05-18T21:41:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8475">
    <title>Re: can't get second ZFS pool to automount</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8475</link>
    <description>&lt;pre&gt;Good question!  The disks are fully spun up and ready even before grub 
loads.  But here are the relevant bits from dmesg anyway:

[ 0.000000] Command line: 
BOOT_IMAGE=/ROOT/ubuntu-1/&amp;lt; at &amp;gt;/boot/vmlinuz-3.2.0-43-generic root=/dev/sdf3 ro 
boot=zfs zfs-bootfs=root_pool/21 quiet splash vt.h
andoff=7
[ 0.810643] ahci 0000:00:1f.2: version 3.0
[ 0.810661] ahci 0000:00:1f.2: PCI INT B -&amp;gt; GSI 22 (level, low) -&amp;gt; IRQ 22
[ 0.810707] ahci 0000:00:1f.2: irq 44 for MSI/MSI-X
[ 0.810752] ahci: SSS flag set, parallel bus scan disabled
[ 0.810782] ahci 0000:00:1f.2: AHCI 0001.0200 32 slots 6 ports 3 Gbps 0x3f 
impl SATA mode
[ 0.810785] ahci 0000:00:1f.2: flags: 64bit ncq sntf stag pm led clo pmp 
pio slum part ccc ems sxs
[ 0.810789] ahci 0000:00:1f.2: setting latency timer to 64
[ 0.848613] scsi0 : ahci
[ 0.848712] scsi1 : ahci
[ 0.848809] scsi2 : ahci
[ 0.848905] scsi3 : ahci
[ 0.849020] scsi4 : ahci
[ 0.849125] scsi5 : ahci
[ 0.849300] ata1: SATA max UDMA/133 abar m2048&amp;lt; at &amp;gt;0xf9ffe800 port 0xf9ffe900 
irq 44
[ 0.849303] ata2: SATA max UDMA/133 abar m2048&amp;lt; at &amp;gt;0xf9ffe800 port 0xf9ffe980 
irq 44
[ 0.849306] ata3: SATA max UDMA/133 abar m2048&amp;lt; at &amp;gt;0xf9ffe800 port 0xf9ffea00 
irq 44
[ 0.849308] ata4: SATA max UDMA/133 abar m2048&amp;lt; at &amp;gt;0xf9ffe800 port 0xf9ffea80 
irq 44
[ 0.849311] ata5: SATA max UDMA/133 abar m2048&amp;lt; at &amp;gt;0xf9ffe800 port 0xf9ffeb00 
irq 44
[ 0.849313] ata6: SATA max UDMA/133 abar m2048&amp;lt; at &amp;gt;0xf9ffe800 port 0xf9ffeb80 
irq 44
[ 0.849343] ahci 0000:04:00.0: PCI INT A -&amp;gt; GSI 16 (level, low) -&amp;gt; IRQ 16
[ 0.849401] ahci 0000:04:00.0: irq 45 for MSI/MSI-X
[ 0.849446] ahci: SSS flag set, parallel bus scan disabled
[ 0.849492] ahci 0000:04:00.0: AHCI 0001.0200 32 slots 2 ports 6 Gbps 0x3 
impl SATA mode
[ 0.849495] ahci 0000:04:00.0: flags: 64bit ncq sntf stag led clo pmp pio 
slum part ccc sxs
[ 0.849501] ahci 0000:04:00.0: setting latency timer to 64
[ 0.849854] scsi6 : ahci
[ 0.849965] scsi7 : ahci
[ 0.850031] ata7: SATA max UDMA/133 abar m512&amp;lt; at &amp;gt;0xfeaffc00 port 0xfeaffd00 
irq 45
[ 0.850036] ata8: SATA max UDMA/133 abar m512&amp;lt; at &amp;gt;0xfeaffc00 port 0xfeaffd80 
irq 45

....

###  Here comes everybody!  /dev/sdf is grub, swap, and root_pool, 
/dev/sda-sde are the data_pool member drives  ###

[ 1.340152] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 1.341741] ata1.00: ATA-8: Hitachi HDS724040ALE640, MJAOA3B0, max UDMA/133
[ 1.341745] ata1.00: 7814037168 sectors, multi 0: LBA48 NCQ (depth 31/32), 
AA
[ 1.343388] ata1.00: configured for UDMA/133
[ 1.343527] scsi 0:0:0:0: Direct-Access ATA Hitachi HDS72404 MJAO PQ: 0 
ANSI: 5
[ 1.343642] sd 0:0:0:0: [sda] 7814037168 512-byte logical blocks: (4.00 
TB/3.63 TiB)
[ 1.343645] sd 0:0:0:0: [sda] 4096-byte physical blocks
[ 1.343675] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 1.343700] sd 0:0:0:0: [sda] Write Protect is off
[ 1.343702] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 1.343740] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[ 1.408941] sda: sda1 sda9
[ 1.409228] sd 0:0:0:0: [sda] Attached SCSI disk
[ 1.464018] Refined TSC clocksource calibration: 2405.454 MHz.
[ 1.464024] Switching to clocksource tsc
[ 1.604140] usb 2-3.3: new low-speed USB device number 3 using ehci_hcd
[ 1.660027] ata2: SATA link down (SStatus 0 SControl 300)
[ 1.816140] usb 2-3.4: new low-speed USB device number 4 using ehci_hcd
[ 2.152024] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 2.153602] ata3.00: ATA-8: Hitachi HDS724040ALE640, MJAOA3B0, max UDMA/133
[ 2.153607] ata3.00: 7814037168 sectors, multi 0: LBA48 NCQ (depth 31/32), 
AA
[ 2.155250] ata3.00: configured for UDMA/133
[ 2.155394] scsi 2:0:0:0: Direct-Access ATA Hitachi HDS72404 MJAO PQ: 0 
ANSI: 5
[ 2.155515] sd 2:0:0:0: [sdb] 7814037168 512-byte logical blocks: (4.00 
TB/3.63 TiB)
[ 2.155518] sd 2:0:0:0: [sdb] 4096-byte physical blocks
[ 2.155535] sd 2:0:0:0: Attached scsi generic sg1 type 0
[ 2.155580] sd 2:0:0:0: [sdb] Write Protect is off
[ 2.155583] sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[ 2.155606] sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[ 2.214578] sdb: sdb1 sdb9
[ 2.214858] sd 2:0:0:0: [sdb] Attached SCSI disk
[ 2.644014] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 2.645597] ata4.00: ATA-8: Hitachi HDS724040ALE640, MJAOA3B0, max UDMA/133
[ 2.645601] ata4.00: 7814037168 sectors, multi 0: LBA48 NCQ (depth 31/32), 
AA
[ 2.647363] ata4.00: configured for UDMA/133
[ 2.647441] scsi 3:0:0:0: Direct-Access ATA Hitachi HDS72404 MJAO PQ: 0 
ANSI: 5
[ 2.647576] sd 3:0:0:0: [sdc] 7814037168 512-byte logical blocks: (4.00 
TB/3.63 TiB)
[ 2.647579] sd 3:0:0:0: [sdc] 4096-byte physical blocks
[ 2.647592] sd 3:0:0:0: Attached scsi generic sg2 type 0
[ 2.647640] sd 3:0:0:0: [sdc] Write Protect is off
[ 2.647643] sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[ 2.647676] sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[ 2.707519] sdc: sdc1 sdc9
[ 2.707793] sd 3:0:0:0: [sdc] Attached SCSI disk
[ 3.136015] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 3.137601] ata5.00: ATA-8: Hitachi HDS724040ALE640, MJAOA3B0, max UDMA/133
[ 3.137605] ata5.00: 7814037168 sectors, multi 0: LBA48 NCQ (depth 31/32), 
AA
[ 3.139251] ata5.00: configured for UDMA/133
[ 3.139339] scsi 4:0:0:0: Direct-Access ATA Hitachi HDS72404 MJAO PQ: 0 
ANSI: 5
[ 3.139454] sd 4:0:0:0: [sdd] 7814037168 512-byte logical blocks: (4.00 
TB/3.63 TiB)
[ 3.139457] sd 4:0:0:0: [sdd] 4096-byte physical blocks
[ 3.139492] sd 4:0:0:0: Attached scsi generic sg3 type 0
[ 3.139509] sd 4:0:0:0: [sdd] Write Protect is off
[ 3.139511] sd 4:0:0:0: [sdd] Mode Sense: 00 3a 00 00
[ 3.139535] sd 4:0:0:0: [sdd] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[ 3.198661] sdd: sdd1 sdd9
[ 3.198937] sd 4:0:0:0: [sdd] Attached SCSI disk
[ 3.628024] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 3.629601] ata6.00: ATA-8: Hitachi HDS724040ALE640, MJAOA3B0, max UDMA/133
[ 3.629606] ata6.00: 7814037168 sectors, multi 0: LBA48 NCQ (depth 31/32), 
AA
[ 3.631237] ata6.00: configured for UDMA/133
[ 3.631314] scsi 5:0:0:0: Direct-Access ATA Hitachi HDS72404 MJAO PQ: 0 
ANSI: 5
[ 3.631450] sd 5:0:0:0: [sde] 7814037168 512-byte logical blocks: (4.00 
TB/3.63 TiB)
[ 3.631453] sd 5:0:0:0: [sde] 4096-byte physical blocks
[ 3.631470] sd 5:0:0:0: Attached scsi generic sg4 type 0
[ 3.631519] sd 5:0:0:0: [sde] Write Protect is off
[ 3.631522] sd 5:0:0:0: [sde] Mode Sense: 00 3a 00 00
[ 3.631553] sd 5:0:0:0: [sde] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[ 3.689425] sde: sde1 sde9
[ 3.689699] sd 5:0:0:0: [sde] Attached SCSI disk
[ 4.120028] ata8: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 4.120306] ata8.00: ATA-9: SanDisk SDSSDP064G, 2.0.0, max UDMA/133
[ 4.120310] ata8.00: 125045424 sectors, multi 1: LBA48 NCQ (depth 31/32)
[ 4.120673] ata8.00: configured for UDMA/133
[ 4.120744] scsi 7:0:0:0: Direct-Access ATA SanDisk SDSSDP06 2.0. PQ: 0 
ANSI: 5
[ 4.120861] sd 7:0:0:0: [sdf] 125045424 512-byte logical blocks: (64.0 
GB/59.6 GiB)
[ 4.120875] sd 7:0:0:0: Attached scsi generic sg5 type 0
[ 4.120953] sd 7:0:0:0: [sdf] Write Protect is off
[ 4.120956] sd 7:0:0:0: [sdf] Mode Sense: 00 3a 00 00
[ 4.120981] sd 7:0:0:0: [sdf] Write cache: enabled, read cache: enabled, 
doesn't support DPO or FUA
[ 4.122058] sdf: sdf1 sdf2 sdf3
[ 4.122379] sd 7:0:0:0: [sdf] Attached SCSI disk

...

###  ...and then here comes ZFS...  ###

[ 6.177889] SPL: Loaded module v0.6.1-rc14
[ 6.178189] zunicode: module license 'CDDL' taints kernel.
[ 6.178192] Disabling lock debugging due to kernel taint
[ 6.732864] ZFS: Loaded module v0.6.1-rc14, ZFS pool version 5000, ZFS 
filesystem version 5
[ 6.737392] SPL: using hostid 0x007f0101

...and that's almost at the end of dmesg.  After that you just have the 
sound board, nvidia drivers, and the network coming up.  (nvidia is 
complaining about not having a vga console, but that shouldn't be either 
here nor there.)

So (and by all means feel free to correct me if you see something I 
don't!), certainly looks like the drives are up in plenty of time before 
ZFS loads.


Just for giggles, I saved my old zfs cache file and rebuilt it one more 
time at the initramfs prompt.  Did a diff on the new vs. old, exactly the 
same.  So really REALLY sure it's not a stale cache file.  (Sure does feel 
like it should be, though!)

Thanks for the suggestion!
&lt;/pre&gt;</description>
    <dc:creator>LosingMyZFS</dc:creator>
    <dc:date>2013-05-18T20:50:01</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8474">
    <title>Re: R720xd + ZoL as iSCSI server</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8474</link>
    <description>&lt;pre&gt;Thanks everybody for the input. Sparse files seems to be the way to go.
Cédric's benchmark shows it's not much worse and several people seem to
agree that issues may happen with zvols. Also I like the concept behind it.
It gives me the option of having a non-ZFS server as a backup:

snapshot the filesystem, rsync the files and you are good to go.

I expect to have this system in production in a month or so and I'll post
the results.

Thanks again!
On May 17, 2013 11:57 PM, "Dan Swartzendruber" &amp;lt;dswartz-AOn2nhsKJLXQT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:

&lt;/pre&gt;</description>
    <dc:creator>Eri Ramos Bastos</dc:creator>
    <dc:date>2013-05-18T20:17:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8473">
    <title>Re: can't get second ZFS pool to automount</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8473</link>
    <description>&lt;pre&gt;Are the disks on the second pool initialized by the time zfs is trying to
build the pool? What does your dmesg output look like with regards to the
disks initialization compared to where zfs is starting up?

t.


On Sat, May 18, 2013 at 10:23 AM, LosingMyZFS &amp;lt;zfs-uIPK+aJd3lDR7s880joybQ&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:

&lt;/pre&gt;</description>
    <dc:creator>Tren Blackburn</dc:creator>
    <dc:date>2013-05-18T19:59:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8472">
    <title>Re: [zfs] Should zpool scrub use cache?</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8472</link>
    <description>&lt;pre&gt;

I believe it is not wrong, as long as the scrub reads all copies
(for mirrors and copies&amp;gt;1) and/or parity (for raidzN) sectors from
original disks and verifies that they are valid. The scrub needs
to walk the block tree however, and to iterate that it needs the
metadata in memory and/or cache. Backtracking via cache is faster,
so as long as this piece of data has been verified on the original
long-term storage, I don't think there's a problem in speeding up
the scrub.

While writing this, I had a thought: the ARC and/or L2ARC devices
might help in fixing the detected corrupted data - if a copy of
that block with a matching checksum is still available in cache...

//Jim

&lt;/pre&gt;</description>
    <dc:creator>Jim Klimov</dc:creator>
    <dc:date>2013-05-18T18:32:50</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8471">
    <title>Re: [zfs] Should zpool scrub use cache?</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8471</link>
    <description>&lt;pre&gt;On 18 May, 2013 - Christ Schlacta sent me these 0,7K bytes:


Scrub verifies the data. Checking the cache does not verify the data.

/Tomas
&lt;/pre&gt;</description>
    <dc:creator>Tomas Forsman</dc:creator>
    <dc:date>2013-05-18T18:25:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8470">
    <title>Should zpool scrub use cache?</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8470</link>
    <description>&lt;pre&gt;I just started a zpool scrub on a pool with a cache device, and a 
strange thought occured to me...  I don't believe a zpool scrub should 
touch cache at all.  I may be wrong, but it seems we want to read all 
the data from the disk.  Reading data from the cache bypasses reading it 
from disk...  Please feel encouraged to correct me if I'm wrong, or 
consider this a bug report if I'm not wrong.

&lt;/pre&gt;</description>
    <dc:creator>Christ Schlacta</dc:creator>
    <dc:date>2013-05-18T18:14:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8469">
    <title>Re: Re: mounting ZFS at boot on Ubuntu oneiric</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8469</link>
    <description>&lt;pre&gt;I took it down ages ago when upstart mountall support was integrated 
into zfs.  :(

&lt;/pre&gt;</description>
    <dc:creator>Christ Schlacta</dc:creator>
    <dc:date>2013-05-18T18:10:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8468">
    <title>Re: can't get second ZFS pool to automount</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8468</link>
    <description>&lt;pre&gt;Since apparently nobody seems to have any ideas whatosever, is there a way
to turn on logging?  Right now I have no visibility as to what zfs is even
*attempting* to do (much less why it's failing!), and every google for zfs
log I try talks about adding a ZIL drive.  Not really what I'm looking for!

--------------------------------------------------
From: "LosingMyZFS" &amp;lt;zfs-uIPK+aJd3lDR7s880joybQ&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
Sent: Friday, May 17, 2013 1:09 PM
To: &amp;lt;zfs-discuss-VKpPRiiRko4/ohRxsw7f2g&amp;lt; at &amp;gt;public.gmane.org&amp;gt;
Subject: [zfs-discuss] can't get second ZFS pool to automount

 



&lt;/pre&gt;</description>
    <dc:creator>LosingMyZFS</dc:creator>
    <dc:date>2013-05-18T17:23:32</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8467">
    <title>Re: mounting ZFS at boot on Ubuntu oneiric</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8467</link>
    <description>&lt;pre&gt;Christ Schlacta &amp;lt;aarcane&amp;lt; at &amp;gt;...&amp;gt; writes: 

FWIW this link is no longer valid.  Could you post a github gist
or other link to an upstart script for ZFS? My google fu has
revealed nothing yet.

Thanks,

Patrick




&lt;/pre&gt;</description>
    <dc:creator>Patrick Andrew</dc:creator>
    <dc:date>2013-05-18T17:00:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8466">
    <title>Request for Information: Boot from ISO</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8466</link>
    <description>&lt;pre&gt;Hi,

  before i am going to mess up my configuration ;-) i would like to 
understand a little bit more:

I know, that grub2 is able to boot off a stored ISO-image from disk 
using casper (and i did it by providing a config file in grub.d).
While not using zfs root, most of my ISO's are stored in a zfs pool. 
Only for booting off the ISO i copied the image over to ext4.
IIRC grub2 should be able to read from a zfs pool (given it is not 
compressed).

But i have not yet managed to get it to use my zfs filesystem stored 
ISO's directly (maybe my understanding of the boot process and grub2 is 
insufficient?).

just in case anyone has done just this, i'd be interested to get their 
working grub.d script as a starting point. - or further explanation - or 
both ;-)

Thank you
UbuntuNewbie

&lt;/pre&gt;</description>
    <dc:creator>ChessDoter</dc:creator>
    <dc:date>2013-05-18T09:14:39</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8465">
    <title>Re: "Compression" restriction on root pool sub-datasets?</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8465</link>
    <description>&lt;pre&gt;Someone should really do https://github.com/Rudd-O/zfs-fedora-installer for Ubuntu.

Turbo Fredriksson &amp;lt;turbo-lqJR/H0eavHQT0dZR+AlfA&amp;lt; at &amp;gt;public.gmane.org&amp;gt; wrote:


&lt;/pre&gt;</description>
    <dc:creator>Manuel Amador (Rudd-O</dc:creator>
    <dc:date>2013-05-18T09:00:35</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8464">
    <title>Re: "Compression" restriction on root pool sub-datasets?</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8464</link>
    <description>&lt;pre&gt;

&lt;/pre&gt;</description>
    <dc:creator>Turbo Fredriksson</dc:creator>
    <dc:date>2013-05-18T08:44:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8463">
    <title>Copying a file from one ZFS to another starves all other processes</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8463</link>
    <description>&lt;pre&gt;With all the ZFS problems I'm having, it seems that it must be a problem 
with my kernel or something, coz otherwise I'm sure there would be a lot 
more people posting issues on the mailing list and a lot less people 
using ZOL!

They all almost seem related to I/O scheduling and buffering (well the 
symptoms of it, not sure what the actual problem is)

One of the problems I'm having is when copying a file (cp fileA fileB), 
it basically starves everything else. Then my VMs (running as file 
backed storage directly on ZFS) get corrupt filesystems reporting that 
the disk controller was not responding (I'm guessing because they are 
trying to write, get to response from the system, so the guest things 
the virtual disk is faulty)

Does anyone else get anything like this?

When copying as well, all the zfs commands are slow to respond (eg. 
zpool iostat takes a few seconds to spit out any info)

Not using dedup or compression, machine has 32GB ram of which 6GB is 
currently free (after running for a few hours)

I'm not really fussed if performance is slow (but performance is 
actually quite good), but if I am doing more than 1 disk related thing 
at a time it is kinda useless.

Thanks, Ryan





&lt;/pre&gt;</description>
    <dc:creator>Ryan How</dc:creator>
    <dc:date>2013-05-18T04:29:32</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8462">
    <title>Re: R720xd + ZoL as iSCSI server</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8462</link>
    <description>&lt;pre&gt;
zvols aren't always worse, but quite a few people have discovered cases
where the performance is distinctly worse.


&lt;/pre&gt;</description>
    <dc:creator>Dan Swartzendruber</dc:creator>
    <dc:date>2013-05-18T02:57:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8461">
    <title>Re: "Compression" restriction on root pool sub-datasets?</title>
    <link>http://permalink.gmane.org/gmane.linux.file-systems.zfs.user/8461</link>
    <description>&lt;pre&gt;Turbo, is there any way you could provide some instructions on how to do a 
native ZFS install? The only guide I've found 
(https://github.com/zfsonlinux/pkg-zfs/wiki/HOWTO-install-Ubuntu-to-a-Native-ZFS-Root-Filesystem) 
says to use a separate ext4 partition for /boot and I'd rather not do it 
that way (right now I've got my whole boot partition set up as a mdadm 
raid-1, so my root zpool will be a mirror).

Thanks.

On Friday, May 17, 2013 5:17:42 AM UTC-7, Turbo Fredriksson wrote:
&amp;gt;&lt;/pre&gt;</description>
    <dc:creator>atomjack-Re5JQEeQqe8AvxtiuMwx3w&lt; at &gt;public.gmane.org</dc:creator>
    <dc:date>2013-05-17T23:39:12</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.file-systems.zfs.user">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.file-systems.zfs.user</link>
  </textinput>
</rdf:RDF>
