headers
Kenneth Vestergaard Schmidt | 1 Sep 2007 01:02
Picon

Re: ZFS: 'checksum mismatch' all over the place

Pawel Jakub Dawidek <pjd <at> FreeBSD.org> writes:
>> I'm not quite sure what knobs to twiddle with, or what values to watch,
>> so any help in this department would be much appreciated. I'm sure it'd
>> be nice to update the Wiki, too, with that info, since the values there
>> don't make things stable.
>
> Is this recent HEAD? If so, this may be because of too much metadata
> caching in ZFS. This was fixed in ZFS, so now ARC can limit metadata
> cache, but this change is not yet in the tree (only in my perforce
> branch).

FreeBSD 7.0-CURRENT #1: Wed Aug 29 15:12:02 CEST 2007

Let me know if you need any testing - the box is pretty unusable in its
current state :)

--

-- 
Kenneth Schmidt
pil.dk
_______________________________________________
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
Yar Tikhiy | 1 Sep 2007 09:48
Picon

New option for newfs(3) to make life with GEOM easier

Hi all,

With some geom(4) modules saving their metadata in the last sectors
of block devices such as disks and partitions, it can be convenient
to reserve space at the end of the device when creating a new file
system in it.  Now newfs(8) allows for specification of file system
size, which can be used for the purpose, but additional calculations
by hand are needed.  OTOH, with the below patch, newfs(8) will grow
a new option to specify the reserved space size directly and in a
error-free way.

The idea and implementation are by Dmitry Morozovsky and yours truly.

Any comments or objections?  Thanks!

--

-- 
Yar

--- //depot/vendor/freebsd/src/sbin/newfs/mkfs.c	2006/10/31 22:39:49
+++ //depot/user/yar/hack/sbin/newfs/mkfs.c	2007/08/31 09:06:24
 <at>  <at>  -107,7 +107,7  <at>  <at> 
 	int fragsperinode, optimalfpg, origdensity, minfpg, lastminfpg;
 	long i, j, cylno, csfrags;
 	time_t utime;
-	quad_t sizepb;
+	off_t sizepb;
 	int width;
 	char tmpbuf[100];	/* XXX this will break in about 2,500 years */
 	union {
--- //depot/vendor/freebsd/src/sbin/newfs/newfs.8	2006/10/31 22:39:49
(Continue reading)

Permalink | Reply | 21 comments |
headers
Poul-Henning Kamp | 1 Sep 2007 10:13
Picon
Favicon

Re: New option for newfs(3) to make life with GEOM easier

In message <20070901074803.GM85633 <at> comp.chem.msu.su>, Yar Tikhiy writes:
>Hi all,
>
>With some geom(4) modules saving their metadata in the last sectors
>of block devices such as disks and partitions, 

1.  If those geom modules do not reduce their providers to prevent
this metadata from being overwritten, they are buggy.

2.  Why not simply allow the -s argument to newfs to be negative so
    "-s -200" means "reserve 200 sectors" ?

--

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk <at> FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
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 | 12 comments |
headers
Yar Tikhiy | 1 Sep 2007 11:23
Picon

Re: New option for newfs(3) to make life with GEOM easier

On Sat, Sep 01, 2007 at 08:13:07AM +0000, Poul-Henning Kamp wrote:
> In message <20070901074803.GM85633 <at> comp.chem.msu.su>, Yar Tikhiy writes:
> >Hi all,
> >
> >With some geom(4) modules saving their metadata in the last sectors
> >of block devices such as disks and partitions, 
> 
> 1.  If those geom modules do not reduce their providers to prevent
> this metadata from being overwritten, they are buggy.

In some scenarios, it can be desirable to newfs first, geom later.

> 2.  Why not simply allow the -s argument to newfs to be negative so
>     "-s -200" means "reserve 200 sectors" ?

A negative argument to -s has been invalid till now, so we propose
a new option for people to express their intentions explicitly.
Personally, I don't mind the "-s -200" syntax, but many people
consider overloaded arguments unintuitive and error-prone.

--

-- 
Yar
_______________________________________________
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 | 11 comments |
headers
Gergely CZUCZY | 1 Sep 2007 11:30
Picon
Favicon

Re: New option for newfs(3) to make life with GEOM easier

On Sat, Sep 01, 2007 at 01:23:10PM +0400, Yar Tikhiy wrote:
> On Sat, Sep 01, 2007 at 08:13:07AM +0000, Poul-Henning Kamp wrote:
> > In message <20070901074803.GM85633 <at> comp.chem.msu.su>, Yar Tikhiy writes:
> > >Hi all,
> > >
> > >With some geom(4) modules saving their metadata in the last sectors
> > >of block devices such as disks and partitions, 
> > 
> > 1.  If those geom modules do not reduce their providers to prevent
> > this metadata from being overwritten, they are buggy.
> 
> In some scenarios, it can be desirable to newfs first, geom later.
True, done it many time myself. Since sysinstall doesn't allow you
to install onto a gmirror array, many install via sysinstall, and gmirror
the system afterwards, which is exactly this situation.

> 
> > 2.  Why not simply allow the -s argument to newfs to be negative so
> >     "-s -200" means "reserve 200 sectors" ?
> 
> A negative argument to -s has been invalid till now, so we propose
> a new option for people to express their intentions explicitly.
> Personally, I don't mind the "-s -200" syntax, but many people
> consider overloaded arguments unintuitive and error-prone.
I think this "-s <negative>" syntax is just fine. As far as
the manual will mention this, there's no problem with it.
Introducing a new exclusive option could result in people
trying to use both at the same time :)

Though for this, geom class manuals should mention how much
(Continue reading)

Permalink | Reply | 8 comments |
headers
Poul-Henning Kamp | 1 Sep 2007 12:39
Picon
Favicon

Re: New option for newfs(3) to make life with GEOM easier

In message <20070901093035.GA18069 <at> harmless.hu>, Gergely CZUCZY writes:

>Though for this, geom class manuals should mention how much
>space do they need for the metadata at the end. Or to simplify
>thing an option for like "reserve some space for (gmirror|gstripe|gfoobar)"
>should be introduced. Or specifing the module and newfs could "ask"
>the geom class for its metadata size that should be reserved.
>Just thinking, sorry if it was too wild...

THe original intent was that you would stick the geom class there
first, then make the filesystem.  Doing things in the other order
is asking for trouble.

--

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk <at> FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
_______________________________________________
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 | 2 comments |
headers
Peter Schuller | 1 Sep 2007 12:15
Gravatar

Re: New option for newfs(3) to make life with GEOM easier

> In some scenarios, it can be desirable to newfs first, geom later.

In particular, moving to root-on-gmirror or root-on-glabel after an 
installation using standard FreeBSD installation media. Not having to jump 
between two disks or otherwise jumping through hoops would be very nice. A 
newfs arg would be controllable through the standard installer, thus  making 
this a lot easier.

--

-- 
/ Peter Schuller

PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schuller <at> infidyne.com>'
Key retrieval: Send an E-Mail to getpgpkey <at> scode.org
E-Mail: peter.schuller <at> infidyne.com Web: http://www.scode.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"
Permalink | Reply | 1 comment |
headers
Yar Tikhiy | 1 Sep 2007 14:09
Picon

Re: New option for newfs(3) to make life with GEOM easier

On Sat, Sep 01, 2007 at 11:30:35AM +0200, Gergely CZUCZY wrote:
> On Sat, Sep 01, 2007 at 01:23:10PM +0400, Yar Tikhiy wrote:
> > On Sat, Sep 01, 2007 at 08:13:07AM +0000, Poul-Henning Kamp wrote:
> 
> > 
> > > 2.  Why not simply allow the -s argument to newfs to be negative so
> > >     "-s -200" means "reserve 200 sectors" ?
> > 
> > A negative argument to -s has been invalid till now, so we propose
> > a new option for people to express their intentions explicitly.
> > Personally, I don't mind the "-s -200" syntax, but many people
> > consider overloaded arguments unintuitive and error-prone.
>
> I think this "-s <negative>" syntax is just fine. As far as
> the manual will mention this, there's no problem with it.
> Introducing a new exclusive option could result in people
> trying to use both at the same time :)

FWIW, the code proposed is robust to specifying both options and
has the following semanics: attemt to create the file system in the
first S sectors but make sure that there are at least R spare sectors
left at the end.  It's documented in the manpage patch. :-)

--

-- 
Yar
_______________________________________________
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 |
headers
Yar Tikhiy | 1 Sep 2007 14:15
Picon

Re: New option for newfs(3) to make life with GEOM easier

On Sat, Sep 01, 2007 at 10:39:33AM +0000, Poul-Henning Kamp wrote:
> In message <20070901093035.GA18069 <at> harmless.hu>, Gergely CZUCZY writes:
> 
> >Though for this, geom class manuals should mention how much
> >space do they need for the metadata at the end. Or to simplify
> >thing an option for like "reserve some space for (gmirror|gstripe|gfoobar)"
> >should be introduced. Or specifing the module and newfs could "ask"
> >the geom class for its metadata size that should be reserved.
> >Just thinking, sorry if it was too wild...
> 
> THe original intent was that you would stick the geom class there
> first, then make the filesystem.  Doing things in the other order
> is asking for trouble.

It can be trickier than putting the geom class there first, but if
the requirements of the geom class are well documented, as in the
gmirror case, there should be nothing wrong with the trick, granting
one knows what he's doing.  After all, we aren't a commercial vendor
trying to hide all dangerous things from the customer to make support
easier. :-) Or am I missing some particular point about geom?

--

-- 
Yar
_______________________________________________
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
Dmitry Morozovsky | 1 Sep 2007 14:10
Picon

Re: New option for newfs(3) to make life with GEOM easier

On Sat, 1 Sep 2007, Poul-Henning Kamp wrote:

PK> In message <20070901093035.GA18069 <at> harmless.hu>, Gergely CZUCZY writes:
PK> 
PK> >Though for this, geom class manuals should mention how much
PK> >space do they need for the metadata at the end. Or to simplify
PK> >thing an option for like "reserve some space for (gmirror|gstripe|gfoobar)"
PK> >should be introduced. Or specifing the module and newfs could "ask"
PK> >the geom class for its metadata size that should be reserved.
PK> >Just thinking, sorry if it was too wild...
PK> 
PK> THe original intent was that you would stick the geom class there
PK> first, then make the filesystem.  Doing things in the other order
PK> is asking for trouble.

Well, while in general I agree with you, there are situations where such 
functionality is desired (hence the patch I originally wrote). Besides 
migrating to gmirror already mentioned, there were situations where I decided 
to insert gcache layers between graid3 and partitions.

Sincerely,
D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:				     marck <at> FreeBSD.org ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck <at> rinet.ru ***
------------------------------------------------------------------------
_______________________________________________
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