headers
Rick Macklem | 1 May 2011 01:45
Picon
Favicon

Re: RFC: make the experimental NFS subsystem the default one

> 
> This comes from mountcritremote:
> 
> case "`mount -d -a -t nfs 2> /dev/null`" in
> *mount_nfs*)
> # Handle absent nfs client support
> load_kld -m nfs nfsclient || return 1
> ;;
> esac
> 
> mount(8) will print "mount_oldnfs" instead of "mount_nfs". Note that
> until you flipped the switch, the exact same error would occur, in
> reverse, on systems running the new stack.
>
Yep, I spotted that, but haven`t had a chance to reproduce it and test
a fix yet. My first attempt at fixing it will be to change the line to:
  load_kld -m nfs nfscl ...

if that works, I`ll see what the rc folks think is the best fix.

> > If you could test a pre-switchover (but recent) client and see if
> > the
> > message shows up, that would be appreciated.
> 
> It does, so it's not something new.
> 
Ok, thanks for testing it, rick
_______________________________________________
freebsd-fs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin Matuska | 1 May 2011 02:09
Picon
Favicon

Re: ZFS v28 for 8.2-STABLE

We plan to MFC v28.

But as this change is quite intrusive to the users, there is no way back
if you upgrade your pool (not upgrading bootcode = not able to boot =
saved by mfsBSD). It will happen when we think it is stable enough to be
in STABLE.

As of me, I am not using it in serious production yet (I am very happy
with v15 + latest patches), but my development servers with v28 seem
pretty stable.

I have updated patch to reflect latest changes (grab latest one):
http://people.freebsd.org/~mm/patches/zfs/v28/

As to your setup, have you tried using a partition as a log device?

File-based devices are generally considered experimental in all ZFS
implementations (including Solaris).

Dňa 30.04.2011 17:44, Pierre Lamy  wrote / napísal(a):
> On 4/29/2011 8:15 PM, Jeremy Chadwick wrote:
>> On Fri, Apr 29, 2011 at 11:20:21PM +0300, Volodymyr Kostyrko wrote:
>>> 28.04.2011 07:37, Ruslan Yakovlev wrote:
>>>> Does actually patch exist for 8.2-STABLE ?
>>>> I probe
>>>> http://people.freebsd.org/~mm/patches/zfs/v28/stable-8-zfsv28-20110317.patch.xz
>>>>
>>>>
>>>> Building failed with:
>>>> can't cd to /usr/src/cddl/usr.bin/zstreamdump
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rick Macklem | 1 May 2011 03:01
Picon
Favicon

Re: newnfs client and statfs

> I just netbooted fresh GENERIC (with irrelevant local patch) over the
> pxe, and got the following:
> 
> # df -h
> Filesystem Size Used Avail Capacity Mounted on
> 192.168.102.110:/usr/home/kostik/build/bsd/DEV/netboot/x -267G 130G
> -539G -32% /
> 
> On the server side, it is up-to-date stable/8 with oldnfs server,
> export is
> /dev/ada1p2 1.8T 129G 1.5T 8% /usr/home
> 
> Do we have some long-typed var lurking in new nfs client code,
> instead of off_t ? I am almost sure this is nfs problem, since I
> booted
> i386 in the same setup month ago, and did not had the compaints from
> sendmail about low space on spool (which is why I noted this issue
> now).
> 
> amd64 kernel (with nfscl loaded as module) correctly reports
> 192.168.102.110:/usr/home/kostik/build/bsd/DEV/netboot/x 1.8T 129G
> 1.5T 8% /
Oops, I never noticed that the "struct statfs" fields had been bumped
to 64bits. I've attached a patch for the client. Could you please test
it? (I'll look in case the server has a similar problem.)

Thanks for reporting it, rick
Attachment (statfs.patch): text/x-patch, 1466 bytes
(Continue reading)






Permalink
| Reply
| 26 comments  
| 



  

  

  





headers


Kostik Belousov
 | 
1 May 2011 04:04






Picon





Re: newnfs client and statfs


On Sat, Apr 30, 2011 at 09:01:08PM -0400, Rick Macklem wrote:
> > I just netbooted fresh GENERIC (with irrelevant local patch) over the
> > pxe, and got the following:
> > 
> > # df -h
> > Filesystem Size Used Avail Capacity Mounted on
> > 192.168.102.110:/usr/home/kostik/build/bsd/DEV/netboot/x -267G 130G
> > -539G -32% /
> > 
> > On the server side, it is up-to-date stable/8 with oldnfs server,
> > export is
> > /dev/ada1p2 1.8T 129G 1.5T 8% /usr/home
> > 
> > Do we have some long-typed var lurking in new nfs client code,
> > instead of off_t ? I am almost sure this is nfs problem, since I
> > booted
> > i386 in the same setup month ago, and did not had the compaints from
> > sendmail about low space on spool (which is why I noted this issue
> > now).
> > 
> > amd64 kernel (with nfscl loaded as module) correctly reports
> > 192.168.102.110:/usr/home/kostik/build/bsd/DEV/netboot/x 1.8T 129G
> > 1.5T 8% /
> Oops, I never noticed that the "struct statfs" fields had been bumped
> to 64bits. I've attached a patch for the client. Could you please test
> it? (I'll look in case the server has a similar problem.)
> 
> Thanks for reporting it, rick

Thank you for the quick fixed. Patch is fine.

(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Dag-Erling Smørgrav
 | 
1 May 2011 05:00






Picon

Gravatar





Re: RFC: make the experimental NFS subsystem the default one


Rick Macklem <rmacklem <at> uoguelph.ca> writes:
> "Dag-Erling Smørgrav" <des <at> des.no> writes:
>> case "`mount -d -a -t nfs 2> /dev/null`" in
>> *mount_nfs*)
>> # Handle absent nfs client support
>> load_kld -m nfs nfsclient || return 1
>> ;;
>> esac
> Yep, I spotted that, but haven`t had a chance to reproduce it and test
> a fix yet. My first attempt at fixing it will be to change the line to:

The simplest fix is to add a mount_oldnfs case to the switch so the
script knows the old NFS stack is already loaded.

DES
--

-- 
Dag-Erling Smørgrav - des <at> des.no
_______________________________________________
freebsd-fs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe <at> freebsd.org"







Permalink
| Reply
| 0 comments  
| 



  

  

  





headers


Alexander Leidinger
 | 
1 May 2011 13:36






Favicon





Re: [ZFS] Booting from zpool created on 4k-sector drive


On Tue, 21 Dec 2010 15:29:01 +0100 "Emil Smolenski" <am <at> raisa.eu.org>
wrote:

> Hello,
> 
> There is a hack to force zpool creation with minimum sector size
> equal to 4k:
> 
> # gnop create -S 4096 ${DEV0}
> # zpool create tank ${DEV0}.nop
> # zpool export tank
> # gnop destroy ${DEV0}.nop
> # zpool import tank
> 
> Zpool created this way is much faster on problematic 4k sector
> drives which lies about its sector size (like WD EARS). This hack
> works perfectly fine when system is running. Gnop layer is created
> only for "zpool create" command -- ZFS stores information about
> sector size in its metadata. After zpool creation one can export the
> pool, remove gnop layer and reimport the pool. Difference can be seen
> in the output from the zdb command:
> 
> - on 512 sector device (2**9 = 512):
> % zdb tank |grep ashift
> ashift=9
> 
> - on 4096 sector device (2**12 = 4096):
> % zdb tank |grep ashift
> ashift=12
> 

(Continue reading)






Permalink
| Reply
| 2 comments  
| 



  

  

  





headers


Bruce Evans
 | 
1 May 2011 14:04






Picon





Re: newnfs client and statfs


On Sat, 30 Apr 2011, Rick Macklem wrote:

> Oops, I never noticed that the "struct statfs" fields had been bumped
> to 64bits. I've attached a patch for the client. Could you please test
> it? (I'll look in case the server has a similar problem.)

Sigh, bugs in this area are very old and still present.

% --- fs/nfsclient/nfs_clport.c.sav	2011-04-30 20:16:39.000000000 -0400
% +++ fs/nfsclient/nfs_clport.c	2011-04-30 20:45:16.000000000 -0400
%  <at>  <at>  -39,6 +39,7  <at>  <at>  __FBSDID("$FreeBSD: head/sys/fs/nfsclien
%   * be the easiest way to handle the port.
%   */
%  #include <sys/hash.h>
% +#include <sys/limits.h>

Only needed to implement a bug.

%  #include <fs/nfs/nfsport.h>
%  #include <netinet/if_ether.h>
%  #include <net/if_types.h>
%  <at>  <at>  -838,20 +839,14  <at>  <at>  void
%  nfscl_loadsbinfo(struct nfsmount *nmp, struct nfsstatfs *sfp, void *statfs)
%  {
%  	struct statfs *sbp = (struct statfs *)statfs;
% -	nfsquad_t tquad;
% 
%  	if (nmp->nm_flag & (NFSMNT_NFSV3 | NFSMNT_NFSV4)) {
%  		sbp->f_bsize = NFS_FABLKSIZE;
% -		tquad.qval = sfp->sf_tbytes;

(Continue reading)






Permalink
| Reply
| 24 comments  
| 



  

  

  





headers


Pawel Jakub Dawidek
 | 
1 May 2011 15:37






Picon

Favicon





Re: TRIM clustering


On Sun, May 01, 2011 at 12:06:56AM +0200, Alexander Leidinger wrote:
> On Sat, 30 Apr 2011 00:28:31 -0700 Jeremy Chadwick
> <freebsd <at> jdc.parodius.com> wrote:
> 
> > On Sat, Apr 30, 2011 at 09:54:02AM +0300, Alexander Motin wrote:
> 
> > Other notes: TRIM needs to be supported on swap as well, and in my
> > opinion this is just as important as it being in UFS.  I'm not sure
> > how one would implement that.
> 
> This brings up the question if a ZFS cache (where the contents do not
> survive a reboot) is completely TRIMmed before used (and normally
> trimmed during use)...

It is not trimmed at all.

--

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://yomoli.com






Permalink
| Reply
| 6 comments  
| 



  

  

  





headers


Rick Macklem
 | 
1 May 2011 16:37






Picon

Favicon





Re: newnfs client and statfs


> 
> % + sbp->f_blocks = sfp->sf_tbytes / NFS_FABLKSIZE;
> % + sbp->f_bfree = sfp->sf_fbytes / NFS_FABLKSIZE;
> % + sbp->f_bavail = sfp->sf_abytes / NFS_FABLKSIZE;
> 
> The conversion for f_bavail still has sign extension bugs. f_bavail
> can be negative on the server. A non-broken (FreeBSD) server passes
> us this negative value as a uint64_t value with the top bit set.

Well, both RFC1813 (NFSv3) and RFC3530 (NFSv4) specify the value on
the wire (sf_abytes) as uint64_t. Therefore a negative value can't
be represented safely and non-FreeBSD clients/servers would be
confused by cheating and putting the negative value on the wire.
(I see you mention this further down.)
The new server is broken in that it does not
check for a negative value. It seems that the best approach for the
server would be to send a 0 when f_bavail < 0. What else can you do
without "cheating" and representing the value in a way that would be
non-interoperable with non-BSD NFS clients?

I agree the above is broken for the case where the high order bit
of sf_abytes is set. How about the following code?

  sbp->f_bavail = (sfp->f_abytes & OFF_MAX) / NFS_FABLKSIZE;

(Yea, I see later in the message that you don't think
 OFF_MAX is the appropriate
 way to represent the largest positive value that can be stored
 in int64_t. As you'll see below, I don't know the correct way to
 express this constant and would be happy to hear how to do it?

(Continue reading)






Permalink
| Reply
| 23 comments  
| 



  

  

  





headers


Bob Friesenhahn
 | 
1 May 2011 17:17






Picon

Picon

Gravatar





Re: TRIM clustering


On Sat, 30 Apr 2011, Alexander Motin wrote:
>>
>> well not all devices take it as a hit.. The suggestion of some sort of
>> clustering is a good one but it should be tunable.
>
> I believe any device should benefit from receiving single 128K request
> instead of 8*16k. Just because of command processing overhead. Am I wrong?

Since I have not seen it mentioned in this discussion thread yet, it 
is worth pointing out that if TRIM has already been issued for a block 
that the filesystem can not re-use that space for storage until the 
TRIM request is completed.  Otherwise in-use blocks might get TRIMmed, 
resulting in filesystem destruction.

If the system should spontaneously reboot, then there may be a 
mismatch between the filesystem's notion of free blocks and the FLASH 
device's notion of free blocks.  In fact, if the kernel panics, the 
device may continue trimming blocks after the system is gone (because 
power is still on).

Bob
--

-- 
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
freebsd-fs <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe <at> freebsd.org"


(Continue reading)






Permalink
| Reply
| 0 comments  
| 



  

  

  

  


  





    



Gmane