headers
Pedro Giffuni | 1 Aug 2008 01:37
Picon
Favicon

Should we change dirent for 64 bit directory cookies ?

Hello fs gurus;

I've been sort of following the DragonFly list wrt to the changes Matt made for his HAMMER fs.
I don't know if anyone is considering a port: he added a lot of stuff to the base system that will be a pain to
port, but he also triggered some bugs in the old BSD code that would be nice to fix on FreeBSD too.

One of the not-*too*-tough things to consider adopting would be 64 directory cookies:

Main commit:
http://leaf.dragonflybsd.org/mailarchive/commits/2007-11/msg00151.html
Follow up for the linuxulator:
http://leaf.dragonflybsd.org/mailarchive/commits/2007-11/msg00153.html

Here is a excerpt of a discussion from the DragonFly Kernel ML (Re: [Tux3] Comparison to Hammer fs design),
that pretty much sums up the issues:
________
...
:>     The cookies are 64 bits in DragonFly.  I'm not sure why Linux would
:>     still be using 32 bit cookies, file offsets are 64 bits so you
:>     should be able to use 64 bit cookies.
:
:It is not Linux that perpetrates this outrage, it is NVFS v2.  We can't
:just tell everybody that their NFS v2 clients are now broken.

    Oh, we don't care about NFSv2 all that much any more.  NFSv3 is the
    bare minimum.  NFSv2 is extremely old, nobody should be using it any
    more.  Even NFSv3 is getting fairly long in the tooth now.

:>     For NFS in DragonFly I use a 64 bit cookie where 32 bits is a hash key
:>     and 32 bits is an iterator to deal with hash collisions.  Poof,
(Continue reading)

Permalink | Reply | 4 comments |
headers
Benjamin Close | 1 Aug 2008 01:25

Re: ZFS patches.

kevin wrote:
> Claus Guttesen wrote:
>> On Sun, Jul 27, 2008 at 2:54 PM, Pawel Jakub Dawidek 
>> <pjd <at> freebsd.org> wrote:
>>  
>>> Hi.
>>>
>>>        http://people.freebsd.org/~pjd/patches/zfs_20080727.patch.bz2
>>>
>>> The patch above contains the most recent ZFS version that could be 
>>> found
>>> in OpenSolaris as of today. Apart for large amount of new 
>>> functionality,
>>> I belive there are many stability (and also performance) improvements
>>> compared to the version from the base system.
>>>
>>> Check out OpenSolaris website to find out the differences between base
>>> system version and patch version.
>>>
>>> Please test, test, test. If I get enough positive feedback, I may be
>>> able to squeeze it into 7.1-RELEASE, but this might be hard.
>>>
>>> If you have any questions, please use mailing lists
>>> (freebsd-fs <at> FreeBSD.org would be the best).
>>>     
>>
>> I applied your patch to a current as of July the 31'st. I had to
>> remove /usr/src and perform a clean csup and remove the two empty
>> files as mentioned in this thread.
>>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Claus Guttesen | 1 Aug 2008 14:19
Picon

Re: ZFS patches.

>> The patch above contains the most recent ZFS version that could be found
>> in OpenSolaris as of today. Apart for large amount of new functionality,
>> I belive there are many stability (and also performance) improvements
>> compared to the version from the base system.
>>
>> Please test, test, test. If I get enough positive feedback, I may be
>> able to squeeze it into 7.1-RELEASE, but this might be hard.
>>
>
> I applied your patch to a current as of July the 31'st. I had to
> remove /usr/src and perform a clean csup and remove the two empty
> files as mentioned in this thread.
>
> I have a areca arc-1680 sas-card and an external sas-cabinet with 16
> sas-drives each 1 TB (931 binary GB). They have been setup in three
> raidz-partitions with five disks each in one zpool and one spare.
>
> There does seem to be a speed-improvement. I nfs-mounted a partition
> from solaris 9 on sparc and is copying approx.400 GB using rsync. I
> saw write of 429 MB/s. The spikes occured every 10 secs. to begin
> with. After some minutes I get writes almost every sec. (watching
> zpool iostat 1). The limit is clearly the network-connection between
> the two hosts. I'll do some internal copying later.
>
> It's to early to say whether zfs is stable (enough) allthough I
> haven't been able to make it halt unless I removed a disk. This was
> with version 6. I'll remove a disk tomorrow and see how it goes.

Replying to my own mail! :-)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Claus Guttesen | 1 Aug 2008 15:38
Picon

Re: ZFS patches.

>>> The patch above contains the most recent ZFS version that could be found
>>> in OpenSolaris as of today. Apart for large amount of new functionality,
>>> I belive there are many stability (and also performance) improvements
>>> compared to the version from the base system.
>>>
>>> Please test, test, test. If I get enough positive feedback, I may be
>>> able to squeeze it into 7.1-RELEASE, but this might be hard.
>>>
>>
>> I applied your patch to a current as of July the 31'st. I had to
>> remove /usr/src and perform a clean csup and remove the two empty
>> files as mentioned in this thread.
>>
>> I have a areca arc-1680 sas-card and an external sas-cabinet with 16
>> sas-drives each 1 TB (931 binary GB). They have been setup in three
>> raidz-partitions with five disks each in one zpool and one spare.
>>
>> There does seem to be a speed-improvement. I nfs-mounted a partition
>> from solaris 9 on sparc and is copying approx.400 GB using rsync. I
>> saw write of 429 MB/s. The spikes occured every 10 secs. to begin
>> with. After some minutes I get writes almost every sec. (watching
>> zpool iostat 1). The limit is clearly the network-connection between
>> the two hosts. I'll do some internal copying later.
>>
>> It's to early to say whether zfs is stable (enough) allthough I
>> haven't been able to make it halt unless I removed a disk. This was
>> with version 6. I'll remove a disk tomorrow and see how it goes.
>
> Replying to my own mail! :-)
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rong-en Fan | 3 Aug 2008 16:43
Picon

journaling filesystem

In NetBSD, they now have metadata journaling support, see

http://www.netbsd.org/changes/#wapbl

I'm not a fs guru, I just want to know what are the status of
BluFFS and UFS journaling support which were mentioned
in recent years.

Thanks,
Rong-En Fan
_______________________________________________
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 | 4 comments |
headers
George Hartzell | 3 Aug 2008 22:59
Gravatar

Re: ZFS patches.

Pawel Jakub Dawidek writes:
 > Hi.
 > 
 > 	http://people.freebsd.org/~pjd/patches/zfs_20080727.patch.bz2
 > 
 > The patch above contains the most recent ZFS version that could be found
 > in OpenSolaris as of today. Apart for large amount of new functionality,
 > I belive there are many stability (and also performance) improvements
 > compared to the version from the base system.
 > 
 > Check out OpenSolaris website to find out the differences between base
 > system version and patch version.
 > 
 > Please test, test, test. If I get enough positive feedback, I may be
 > able to squeeze it into 7.1-RELEASE, but this might be hard.
 > [...]

Thanks Pawel!

I have a version of -CURRENT from 7-29-08 running on an AMD 3800+ with
2GB of RAM and two Seagate ST3300622AS disks.

This machine was previously running zfs filesystems using -STABLE.
It uses a root on zfs configuration based on

  http://yds.coolrat.org/zfsboot.shtml 

I tested for stablilty by firing up a bunch of xterms on my desktop
workstation, ssh'ing into the system and running a bunch of stuff in
parallel.  The list of stuff settled down to be: two while(1) loops
(Continue reading)

Permalink | Reply | 0 comments |
headers
FreeBSD bugmaster | 4 Aug 2008 13:06
Picon
Favicon

Current problem reports assigned to freebsd-fs <at> FreeBSD.org

Current FreeBSD problem reports
Critical problems
Serious problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/93942   fs         [vfs] [patch] panic: ufs_dirbad: bad dir (patch from D
o kern/112658  fs         [smbfs] [patch] smbfs and caching problems (resolves b
o kern/114676  fs         [ufs] snapshot creation panics: snapacct_ufs2: bad blo
o kern/116170  fs         [panic] Kernel panic when mounting /tmp
o bin/121072   fs         [smbfs] mount_smbfs(8) cannot normally convert the cha
o bin/122172   fs         [fs]: amd(8) automount daemon dies on 6.3-STABLE i386,
o kern/122888  fs         [zfs] zfs hang w/ prefetch on, zil off while running t

7 problems total.

Non-critical problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o bin/113049   fs         [patch] [request] make quot(8) use getopt(3) and show 
o bin/113838   fs         [patch] [request] mount(8): add support for relative p
o bin/114468   fs         [patch] [request] add -d option to umount(8) to detach
o kern/114847  fs         [ntfs] [patch] [request] dirmask support for NTFS ala 
o kern/114955  fs         [cd9660] [patch] [request] support for mask,dirmask,ui
o bin/118249   fs         mv(1): moving a directory changes its mtime
o kern/124621  fs         [ext3] Cannot mount ext2fs partition
o kern/125536  fs         [ext2fs] ext 2 mounts cleanly but fails on commands li

8 problems total.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Doug Rabson | 4 Aug 2008 15:25

Re: Which GSSAPI library does FreeBSD use?


On 29 Jul 2008, at 15:27, Rick Macklem wrote:

>
>
> On Tue, 29 Jul 2008, Dag-Erling Smørgrav wrote:
>
>> Rick Macklem <rmacklem <at> uoguelph.ca> writes:
>>> Hope this isn't too simplistic for this list, but I need to know  
>>> which
>>> GSSAPI library sources are being used. They don't appear to be  
>>> either
>>> vanilla MIT nor Heimdal.
>>
>> Homegrown (by Doug Rabson, dfr <at> ) with portions borrowed from Heimdal.
>>
> Ok, thanks. I was able to work around my problem by statically linking
> my gssd against libraries built from vanilla Heimdal sources. It looks
> like it inherited the heimdal-0.6 bug, which ignores the lack of the
> GSS_C_SEQUENCE_FLAG and checks it even if it wasn't specified. This
> breaks the client side of RPCSEC_GSS, since somewhat out-of-order
> Sun RPCs, is normal. (RPCSEC_GSS uses a window of recent seq#s to
> protect against replay attempts.)
>
> Should I email Doug or submit a bug report, to see if someone is  
> willing
> to work on fixing this?

Try using current - I updated heimdal to 1.1 in current.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Oliver Fromme | 4 Aug 2008 17:18
Picon

Re: Should we change dirent for 64 bit directory cookies ?

Pedro Giffuni wrote:
 > I've been sort of following the DragonFly list wrt to the changes Matt made for his HAMMER fs.
 > I don't know if anyone is considering a port: he added a lot of stuff to the base system that will be a pain to
port, but he also triggered some bugs in the old BSD code that would be nice to fix on FreeBSD too.
 > 
 > One of the not-*too*-tough things to consider adopting would be 64 directory cookies:
 > 
 > Main commit:
 > http://leaf.dragonflybsd.org/mailarchive/commits/2007-11/msg00151.html
 > Follow up for the linuxulator:
 > http://leaf.dragonflybsd.org/mailarchive/commits/2007-11/msg00153.html
 > 
 > Here is a excerpt of a discussion from the DragonFly Kernel ML (Re: [Tux3] Comparison to Hammer fs design),
that pretty much sums up the issues:
 > [...]
 > 
 >     I'd recommend dropping support for NFSv2.  It is not really worth 
 >     supporting any more.   Does it even support 64 bit inodes? (I don't 
 >     remember), or 64 bit file offsets?  NFSv2 is garbage.

One of the problems with that is that our PXE boot loader
requires NFSv2 support, AFAIK.  If you drop NFSv2 server
support from the kernel, you can't boot PXE clients from
it anymore, unless someone adds NFSv3 support to the boot
loader.

Best regards
   Oliver

--

--
(Continue reading)

Permalink | Reply | 3 comments |
headers
Pedro Giffuni | 4 Aug 2008 18:34
Picon
Favicon

Re: Should we change dirent for 64 bit directory cookies ?

--- Lun 4/8/08, Oliver Fromme <olli <at> ----.----x.de> ha scritto:

...

One of the problems with that is that our PXE boot loader
requires NFSv2 support, AFAIK.  If you drop NFSv2 server
support from the kernel, you can't boot PXE clients from
it anymore, unless someone adds NFSv3 support to the boot
loader.

Best regards
   Oliver

____

I see, thanks for the explanation... yes, it sounds like this will have to wait a while then. I am looking at
the Intel PXE spec and there is no mention about NFS. I will investigate a bit more but I guess there is a new
wish for the PXE guys ;-).

cheers,

    Pedro.

      Posta, news, sport, oroscopo: tutto in una sola pagina. 
Crea l&#39;home page che piace a te!
www.yahoo.it/latuapagina
_______________________________________________
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 | 2 comments |

Gmane