<?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://permalink.gmane.org/gmane.os.freebsd.devel.file-systems">
    <title>gmane.os.freebsd.devel.file-systems</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems</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.os.freebsd.devel.file-systems/15112"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15111"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15110"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15109"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15108"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15107"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15106"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15105"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15104"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15103"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15102"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15101"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15100"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15099"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15098"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15097"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15096"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15095"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15094"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15093"/>
      </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.os.freebsd.devel.file-systems/15112">
    <title>Re: NFS Server Limiting open port RST response</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15112</link>
    <description>&lt;pre&gt;
Looks like your issue is not the same after all. The fix for the issue
I had in mind is in 9.0 since BETA2.

--Artem.

_______________________________________________
freebsd-fs&amp;lt; at &amp;gt;freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe&amp;lt; at &amp;gt;freebsd.org"

&lt;/pre&gt;</description>
    <dc:creator>Artem Belevich</dc:creator>
    <dc:date>2012-05-22T22:42:20</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15111">
    <title>Re: NFS Server Limiting open port RST response</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15111</link>
    <description>&lt;pre&gt;Hi,

I'm using "9.0-RELEASE #0: Tue Jan  3 07:46:30 UTC 2012"

Thanks,

On Tue, May 22, 2012 at 12:26 PM, Artem Belevich &amp;lt;art&amp;lt; at &amp;gt;freebsd.org&amp;gt; wrote:
_______________________________________________
freebsd-fs&amp;lt; at &amp;gt;freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe&amp;lt; at &amp;gt;freebsd.org"

&lt;/pre&gt;</description>
    <dc:creator>bsalinux&lt; at &gt;gmail.com</dc:creator>
    <dc:date>2012-05-22T21:16:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15110">
    <title>Re: NFS Server Limiting open port RST response</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15110</link>
    <description>&lt;pre&gt;
Which FreeBSD version are you using? This problem sounds rather
similar to what I've fixed last fall in head&amp;lt; at &amp;gt;225234, stable/8&amp;lt; at &amp;gt;225384

--Artem
_______________________________________________
freebsd-fs&amp;lt; at &amp;gt;freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe&amp;lt; at &amp;gt;freebsd.org"

&lt;/pre&gt;</description>
    <dc:creator>Artem Belevich</dc:creator>
    <dc:date>2012-05-22T19:26:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15109">
    <title>NFS Server Limiting open port RST response</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15109</link>
    <description>&lt;pre&gt;Hi,

I have a FreeBSD + ZFS server configured as NFS server. This server is
being used to store regressions that are generated over a period of
2-3 days. Time to time nfs would drop the mount and the program fails
to find the output directory (nfs automount). On the other hand if I
use Linux NFS server to host this space, I see no issues.

Time to time I see messages like these in the logs:

Limiting open port RST response from 334 to 200 packets/sec

It seems that the automount dismounts the server while the regressions
are being computed and the output is idle. I even kept one terminal
window open on the compute server that is "cd" into the output
directory so that it prevents the dismounting the automount but it
still fails.

Do I need to tweak any parameters? Can I stop dismounting (from NFS
server side)?

Any help would be appreciated.

Thanks.
_______________________________________________
freebsd-fs&amp;lt; at &amp;gt;freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any&lt;/pre&gt;</description>
    <dc:creator>bsalinux&lt; at &gt;gmail.com</dc:creator>
    <dc:date>2012-05-22T18:35:05</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15108">
    <title>Re: kern/136865: [nfs] [patch] NFS exports atomic and on-the-fly atomic updates</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15108</link>
    <description>&lt;pre&gt;Hello,

On Sun, May 20, 2012 at 08:10:04AM +0000, Martin Birgmeier wrote:

The exports(5) manual page says that address specifications must be specified
after options.  The nfs.exports(5) file format allows to use options after
address specifications, so they can overwrite previously specified options.

It is possible to specify all settings for one file system in one line,
no ';' like separators are required.

For example line:

/fs -ro -sec krb5 1.1.1.1 -nfsv4 no -rw 2.2.2.2 -sec sys -nfsv4 yes 3.3.3.3

will be translated to ("nfse -t ..." output):

Pathname /fs
    Export specifications:
        -rw -sec sys -maproot=-2:-2 -host 3.3.3.3
        -rw -sec krb5 -maproot=-2:-2 -nfsv4 no -host 2.2.2.2
        -ro -sec krb5 -maproot=-2:-2 -host 1.1.1.1


In short: if nfse is run in compatible mode with mountd ("nfse -C ..."),
then it is more compatible with exports(5) than mountd is.  If one did
not follow rules of exports(5), then "nfse -C ..." can be incompatible
with mountd.

If nfse is run in native nfs.exp&lt;/pre&gt;</description>
    <dc:creator>Andrey Simonenko</dc:creator>
    <dc:date>2012-05-22T08:04:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15107">
    <title>Re: zpool import reboots computer</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15107</link>
    <description>&lt;pre&gt;Hi freebsd-fs,

my zpool is still not importable. :(

I've got some tips during the last days, but none of them changed
the error messages below in the second "screenshot". The zdb -lu
output is in sync for all disks.

I've replaced the boot mirror (FreeBSD 8.3-RELEASE-p1, gptzfsboot)
with a plain FreeBSD 9.0-STABLE (gptboot, single disk, / on ufs)
with the patched vdev_mirror.c and finally managed to get a crashdump
while trying to import the zpool zdata using "zpool import -f -R
/angus.zdata -d /dev/gpt zdata":

https://www.server-king.de/download/zfs-crash-debug/backtrace.zdata.crash.txt

The patch I've used is here:

https://www.server-king.de/download/zfs-crash-debug/vdev_mirror.c.patch.txt

Otherwise it would crash before the same way as with plain RELENG_8_3.

Do you need any more information?

Thanks for any help,
Knarf

P.S.: The latest changes seen in
http://www.freebsd.org/cgi/cvsweb.cgi/src/cddl/contrib/opensolaris/lib/libzfs/common/libzfs_dataset.c
(SVN rev 235702) do not seem to be related with&lt;/pre&gt;</description>
    <dc:creator>Frank Bartels</dc:creator>
    <dc:date>2012-05-21T21:36:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15106">
    <title>Current problem reports assigned to freebsd-fs&lt; at &gt;FreeBSD.org</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15106</link>
    <description>&lt;pre&gt;Note: to view an individual PR, use:
  http://www.freebsd.org/cgi/query-pr.cgi?pr=(number).

The following is a listing of current problems submitted by FreeBSD users.
These represent problem reports covering all versions including
experimental development code and obsolete releases.


S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/168158  fs         [zfs] incorrect parsing of sharenfs options in zfs (fs
o kern/167979  fs         [ufs] DIOCGDINFO ioctl does not work on 8.2 file syste
o kern/167977  fs         [smbfs] mount_smbfs results are differ when utf-8 or U
o kern/167905  fs         [zfs] zfs set canmount=on UNMOUNTS dataset
o kern/167688  fs         [fusefs] Incorrect signal handling with direct_io
o kern/167685  fs         [zfs] ZFS on USB drive prevents shutdown / reboot
o kern/167612  fs         [portalfs] The portal file system gets stuck inside po
o kern/167272  fs         [zfs] ZFS Disks reordering causes ZFS to pick &lt;/pre&gt;</description>
    <dc:creator>FreeBSD bugmaster</dc:creator>
    <dc:date>2012-05-21T11:07:11</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15105">
    <title>Re: kern/168158: [zfs] incorrect parsing of sharenfs options in zfs(fsshare.c)</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15105</link>
    <description>&lt;pre&gt;Old Synopsis: incorrect parsing of sharenfs options in zfs (fsshare.c)
New Synopsis: [zfs] incorrect parsing of sharenfs options in zfs (fsshare.c)

Responsible-Changed-From-To: freebsd-bugs-&amp;gt;freebsd-fs
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon May 21 08:32:13 UTC 2012
Responsible-Changed-Why: 
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=168158
_______________________________________________
freebsd-fs&amp;lt; at &amp;gt;freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe&amp;lt; at &amp;gt;freebsd.org"

&lt;/pre&gt;</description>
    <dc:creator>linimon&lt; at &gt;FreeBSD.org</dc:creator>
    <dc:date>2012-05-21T08:32:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15104">
    <title>Re: Mirror of Raidz for data reliability</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15104</link>
    <description>&lt;pre&gt;2012/5/19 Daniel Kalchev &amp;lt;daniel&amp;lt; at &amp;gt;digsys.bg&amp;gt;


Yeap, you are right! In my environment I'm not doing ACTIVE-ACTIVE servers,
so, one of those controller always will be in stand-by mode. In case
someone need to have all data available in both machines at the same time,
the best choice right now is use HAST.

But my solution is to reach another necessity.

Best Regards,
&lt;/pre&gt;</description>
    <dc:creator>Marcelo Araujo</dc:creator>
    <dc:date>2012-05-21T03:18:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15103">
    <title>Re: Mirror of Raidz for data reliability</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15103</link>
    <description>&lt;pre&gt;2012/5/19 Trent Nelson &amp;lt;trent&amp;lt; at &amp;gt;snakebite.org&amp;gt;

Yeap, you can use CARP + anything else to help you make it work.
However in my case, if I have a JBOD fail, I want to be able to import the
another JBOD with all data, so in my case I need raidz + vdev(mirror).

Currently, I made a patch and now it works pretty well, but I'm doing some
more tests to check if I'll face out any problem.

Best Regards,
&lt;/pre&gt;</description>
    <dc:creator>Marcelo Araujo</dc:creator>
    <dc:date>2012-05-21T03:15:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15102">
    <title>Re: kern/139597: [patch] [tmpfs] tmpfs initializes va_gen butdoesn't update it on vnode change</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15102</link>
    <description>&lt;pre&gt;Synopsis: [patch] [tmpfs] tmpfs initializes va_gen but doesn't update it on vnode change

State-Changed-From-To: open-&amp;gt;closed
State-Changed-By: gleb
State-Changed-When: Sun May 20 13:27:09 UTC 2012
State-Changed-Why: 
Not a bug, only ZFS updates generation number.

http://www.freebsd.org/cgi/query-pr.cgi?pr=139597
_______________________________________________
freebsd-fs&amp;lt; at &amp;gt;freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe&amp;lt; at &amp;gt;freebsd.org"

&lt;/pre&gt;</description>
    <dc:creator>gleb&lt; at &gt;FreeBSD.org</dc:creator>
    <dc:date>2012-05-20T13:27:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15101">
    <title>Re: kern/139597: [patch] [tmpfs] tmpfs initializes va_gen butdoesn't update it on vnode change</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15101</link>
    <description>&lt;pre&gt;Synopsis: [patch] [tmpfs] tmpfs initializes va_gen but doesn't update it on vnode change

State-Changed-From-To: open-&amp;gt;
State-Changed-By: gleb
State-Changed-When: Sun May 20 12:32:55 UTC 2012
State-Changed-Why: 
Not a bug, only ZFS updates generation number.

http://www.freebsd.org/cgi/query-pr.cgi?pr=139597
_______________________________________________
freebsd-fs&amp;lt; at &amp;gt;freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe&amp;lt; at &amp;gt;freebsd.org"

&lt;/pre&gt;</description>
    <dc:creator>gleb&lt; at &gt;FreeBSD.org</dc:creator>
    <dc:date>2012-05-20T12:35:12</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15100">
    <title>Re: kern/136865: [nfs] [patch] NFS exports atomic and on-the-fly atomic updates</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15100</link>
    <description>&lt;pre&gt;The following reply was made to PR kern/136865; it has been noted by GNATS.

From: Martin Birgmeier &amp;lt;Martin.Birgmeier&amp;lt; at &amp;gt;aon.at&amp;gt;
To: bug-followup&amp;lt; at &amp;gt;FreeBSD.org, simon&amp;lt; at &amp;gt;comsys.ntu-kpi.kiev.ua
Cc:  
Subject: Re: kern/136865: [nfs] [patch] NFS exports atomic and on-the-fly
 atomic updates
Date: Sun, 20 May 2012 10:04:01 +0200

 Dear Andrey,
 
 It seems that you have done some great work here, and I would really 
 like to see this integrated into the core FreeBSD distribution (I was 
 the submitter of http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/131342).
 
 I would like to try out your patches and have two questions:
 
 - Do your patches support multiple zfs sharenfs specifications as 
 proposed in http://www.freebsd.org/cgi/query-pr.cgi?pr=147881 (I am 
 using this)?
 
 - Could you give a concise list of incompatibilities (and even 
 regressions if they should exist at all) of your solution compared to 
 the standard one? - As to the advantages, I am already convinced. :-)
 
 Thank you &amp;amp; regards,
 
 Martin
 
_____&lt;/pre&gt;</description>
    <dc:creator>Martin Birgmeier</dc:creator>
    <dc:date>2012-05-20T08:10:04</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15099">
    <title>[patch] Broken RLIMIT_FSIZE handling in ZFS</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15099</link>
    <description>&lt;pre&gt;Hello,

vn_rlimit_fsize takes uio-&amp;gt;uio_offset and uio-&amp;gt;uio_resid into account
when determining whether given write would exceed RLIMIT_FSIZE.

When APPEND flag is specified, ZFS updates uio-&amp;gt;uio_offset to point to the
end of file.

But this happens after a call to vn_rlimit_fsize, so vn_rlimit_fsize check
can be rendered ineffective by thread that opens some file with O_APPEND
and lseeks below RLIMIT_FSIZE before calling write.

This fixes the problem for me:
http://student.agh.edu.pl/~mjguzik/patches/zfs-rlimit-fsize.patch

Slightly modified testcase stolen from pr standards/164793:
http://student.agh.edu.pl/~mjguzik/patches/writelimit.c

Without the patch this testacase will just finish by producing 80000 bytes
file on ZFS.

On UFS it gives the following output:
failed when adding 27 bytes after 59994 bytes (error: File too large)

Same happens on ZFS with the patch.

&lt;/pre&gt;</description>
    <dc:creator>Mateusz Guzik</dc:creator>
    <dc:date>2012-05-19T20:22:13</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15098">
    <title>Book on FFS</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15098</link>
    <description>&lt;pre&gt;Is there a book (or other documentation) about FFS giving more details than the 4.4BSD bible?

I'm writing a Perl script that takes a subset of newfs's arguments, reads a find -ls output and computes the fragmentation/bookkeeping overhead for that particular data set. (The intent is to find out how much the newfs parameters actually matter in terms of overhead for that given data set.)

In the course of researching what the exact overhead for the free list, inodes and CG heads is, I learned (from discussions on NetBSD's tech-kern list and from reading ufs/ffs/fs.h and mkfs.c) various "interesting" things like files that need indirect blocks not being allocated fragments, "number of blocks" and "number of data blocks" (i.e. fs_size and fs_dsize) being in units of fragments, not blocks. I suspect there is way more for me to learn in this field._______________________________________________
freebsd-fs&amp;lt; at &amp;gt;freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to&lt;/pre&gt;</description>
    <dc:creator>Edgar Fuß</dc:creator>
    <dc:date>2012-05-19T16:50:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15097">
    <title>Re: Does -CURRENT support *Plug "computers?</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15097</link>
    <description>&lt;pre&gt;Hello, Gary.
You wrote 19 мая 2012 г., 18:23:53:

GJ&amp;gt; It would make more sense to ask this question on freebsd-arm.
  ooops, sorry, missed embedded&amp;lt; at &amp;gt; :)



&lt;/pre&gt;</description>
    <dc:creator>Lev Serebryakov</dc:creator>
    <dc:date>2012-05-19T15:48:47</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15096">
    <title>Re: Does -CURRENT support *Plug "computers?</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15096</link>
    <description>&lt;pre&gt;On Sat, 19 May 2012 18:01:26 +0400
Lev Serebryakov &amp;lt;lev&amp;lt; at &amp;gt;FreeBSD.org&amp;gt; wrote:


It would make more sense to ask this question on freebsd-arm.

&lt;/pre&gt;</description>
    <dc:creator>Gary Jennejohn</dc:creator>
    <dc:date>2012-05-19T14:23:53</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15095">
    <title>Does -CURRENT support *Plug "computers?</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15095</link>
    <description>&lt;pre&gt;Hello, Freebsd-fs.

  Does -CURRENT support SheevaPlug/GuruPlug/DreamPlug computers, based
on Marvell ARM CPUs?

&lt;/pre&gt;</description>
    <dc:creator>Lev Serebryakov</dc:creator>
    <dc:date>2012-05-19T14:01:26</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15094">
    <title>Re: Mirror of Raidz for data reliability</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15094</link>
    <description>&lt;pre&gt;

On 18.05.12 19:55, Trent Nelson wrote:

The proper way of doing it is "not import it at all". ZFS is not an 
shared filesystem.

If you have the second host mount the zpool even if read-only, you only 
guarantee that data on the pool will not be corrupted, but you cannot 
avoid the second "read-only" host panic or otherwise crash if it tries 
to access data which is no longer where it thinks it is, because the 
second host doesn't have access to the primary host's in-memory metadata 
about ZFS. Since ZFS is copy on write filesystem, chances are you will 
be accessing data that is no longer valid. Refreshing the internal ZFS 
state between two or more hosts is non-trivial (if it was, Sun would 
have done this, as it suits their usage) and in any case performance 
will suffer at least as much as an true networked filesystem does, 
compared to "native" ZFS.

Daniel

_______________________________________________
freebsd-fs&amp;lt; at &amp;gt;freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsub&lt;/pre&gt;</description>
    <dc:creator>Daniel Kalchev</dc:creator>
    <dc:date>2012-05-19T10:13:28</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15093">
    <title>Re: NAND Framework in HEAD.</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15093</link>
    <description>&lt;pre&gt;
If this NAND filesystem is similar to others I am aware of (e.g. 
JFFS2, UBIFS), it is intended to be used directly with NAND FLASH 
devices (i.e. a chip).  This is common for embedded type applications.

USB Flash Disks are a type of SSD and are arranged as logical disk 
blocks.  They are not suitable for use with a NAND filesystem.

Regardless, the availability of a NAND filesystem will make FreeBSD 
much more competitive for use in embedded applications (where Linux 
currently dominates).

Bob
&lt;/pre&gt;</description>
    <dc:creator>Bob Friesenhahn</dc:creator>
    <dc:date>2012-05-18T18:36:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15092">
    <title>Re: zpool import reboots computer</title>
    <link>http://permalink.gmane.org/gmane.os.freebsd.devel.file-systems/15092</link>
    <description>&lt;pre&gt;Hi freebsd-fs,

I have a similar problem like Martin.

It started a while ago with a broken zfs, I was no longer able to
delete some files on /home/ncvs:

Checking setuid files and devices:
find: /home/ncvs/del/efax/Attic/pkg-comment,v: Bad file descriptor
find: /home/ncvs/del/libsyncml/files: No such file or directory

Two days ago the machine started rebooting every two hours, directly
after syncing my local cvsup-server.

So I renamed the zfs /home/ncvs to /home/ncvs.del and tried to
destroy it including its snapshots. The machine crashed again and
now I'm unable to import the pool.

First I've seen this backtrace:

https://www.server-king.de/download/DSC02742.medium.JPG

Then I've added the three blocks above to vdev_mirror.c. It still
crashes, but the backtrace has changed:

https://www.server-king.de/download/DSC02744.medium.JPG

...
calltrap
zio_checksum_verify
zio_execute
arc_read_nolock
arc_read
...

This is FreeBSD 8.3-RELEASE-p1 amd64 on a Xeon X5650 with 24 GByte
RAM and 12 hard disks and 2 SSDs.&lt;/pre&gt;</description>
    <dc:creator>Frank Bartels</dc:creator>
    <dc:date>2012-05-18T17:52:25</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.os.freebsd.devel.file-systems">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.os.freebsd.devel.file-systems</link>
  </textinput>
</rdf:RDF>

