headers
linimon | 2 Mar 2008 07:20
Picon
Favicon

Re: kern/105390: [geli] filesystem on a md backed by sparse file with softupdates enabled leads to wdrain livelock.

Synopsis: [geli] filesystem on a md backed by sparse file with softupdates enabled leads to wdrain livelock.

State-Changed-From-To: feedback->closed
State-Changed-By: linimon
State-Changed-When: Sun Mar 2 06:20:40 UTC 2008
State-Changed-Why: 
Feedback timeout (> 6 months).

http://www.freebsd.org/cgi/query-pr.cgi?pr=105390
Permalink | Reply | 2 comments |
headers
FreeBSD bugmaster | 3 Mar 2008 12:07
Picon
Favicon

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

Current FreeBSD problem reports
Critical problems
Serious problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o kern/73177   geom       kldload geom_* causes panic due to memory exhaustion
o kern/76538   geom       [gbde] nfs-write on gbde partition stalls and continue
o kern/83464   geom       [geom] [patch] Unhandled malloc failures within libgeo
o kern/84556   geom       [geom] GBDE-encrypted swap causes panic at shutdown
o kern/87544   geom       [gbde] mmaping large files on a gbde filesystem deadlo
s kern/89102   geom       [geom_vfs] [panic] panic when forced unmount FS from u
o bin/90093    geom       fdisk(8) incapable of altering in-core geometry
o kern/90582   geom       [geom_mirror] [panic] Restore cause panic string (ffs_
o kern/98034   geom       [geom] dereference of NULL pointer in acd_geom_detach 
o kern/104389  geom       [geom] [patch] sys/geom/geom_dump.c doesn't encode XML
o kern/113419  geom       [geom] geom fox multipathing not failing back
o kern/113957  geom       [gmirror] gmirror is intermittently reporting a degrad
o kern/115572  geom       [gbde] [patch] gbde partitions fail at 28bit/48bit LBA
o kern/120021  geom       net-p2p/qbittorrent crashes system when it works thoug
o kern/120231  geom       [geom] GEOM_CONCAT error adding second drive

15 problems total.

Non-critical problems

S Tracker      Resp.      Description
--------------------------------------------------------------------------------
o bin/78131    geom       gbde "destroy" not working.
o kern/79251   geom       [2TB] newfs fails on 2.6TB gbde device
(Continue reading)

Permalink | Reply | 0 comments |
headers
vwe | 5 Mar 2008 03:51
Picon
Favicon

Re: kern/121364: [gmirror] Removing all providers create a "zombie" mirror

Synopsis: [gmirror] Removing all providers create a "zombie" mirror

Responsible-Changed-From-To: freebsd-bugs-≥freebsd-geom
Responsible-Changed-By: vwe
Responsible-Changed-When: Wed Mar 5 02:50:55 UTC 2008
Responsible-Changed-Why: 

Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=121364
Permalink | Reply | 0 comments |
headers
vwe | 5 Mar 2008 04:38
Picon
Favicon

Re: kern/121364: [gmirror] Removing all providers create a "zombie" mirror

Synopsis: [gmirror] Removing all providers create a "zombie" mirror

State-Changed-From-To: open->feedback
State-Changed-By: vwe
State-Changed-When: Wed Mar 5 03:36:46 UTC 2008
State-Changed-Why: 
Please provide output of `gmirror list'

http://www.freebsd.org/cgi/query-pr.cgi?pr=121364
Permalink | Reply | 0 comments |
headers
Kena | 5 Mar 2008 08:30
Favicon

Re: kern/121364: [gmirror] Removing all providers create a "zombie" mirror

The following reply was made to PR kern/121364; it has been noted by GNATS.

From: Kena <kena <at> vodka-pomme.net>
To: bug-followup <at> FreeBSD.org
Cc:  
Subject: Re: kern/121364: [gmirror] Removing all providers create a "zombie" mirror
Date: Wed, 5 Mar 2008 08:26:24 +0100

 Hi,

 since the two aforementioned disks (da0 and da1) are now in production  
 elsewhere, I am repeating the test with ggate. I believe the results  
 are similar as in my previous report.

 0. for i in 0 1; do dd if=/dev/zero of=d$i bs=1024 count=100k; ggatel  
 create d$i; done

 1. gmirror label -h test1 ggate0 ggate1; gmirror list

 Geom name: test1
 State: COMPLETE
 Components: 2
 Balance: split
 Slice: 4096
 Flags: NONE
 GenID: 0
 SyncID: 1
 ID: 538186880
 Providers:
 1. Name: mirror/test1
(Continue reading)

Permalink | Reply | 0 comments |
headers
Miroslav Lachman | 7 Mar 2008 10:39
Picon

GEOM_JOURNAL: Cannot suspend file system /vol0 (error=35)

Hi,

today I saw this error in messages:

: fsync: giving up on dirty
: 0xc5564110: tag devfs, type VCHR
: usecount 1, writecount 0, refcount 78 mountedhere 0xc54ef800
: flags ()
: v_object 0xc556645c ref 0 pages 1146
: lock type devfs: EXCL (count 1) by thread 0xc5236a50 (pid 39)
: dev mirror/gm0s2e.journal
: GEOM_JOURNAL: Cannot suspend file system /vol0 (error=35).

Is it something harmful, or is it "normal" behavior? It was in time when 
generating backup (high disk I/O).
Gjournal is on top of gmirrored SATA disks.

mirror/gm0s2d is 2GB journal provider
mirror/gm0s2e.journal is 380GB data provider

Miroslav Lachman
Permalink | Reply | 2 comments |
headers
Eric Anderson | 7 Mar 2008 13:33
Picon
Favicon
Gravatar

Re: GEOM_JOURNAL: Cannot suspend file system /vol0 (error=35)

Miroslav Lachman wrote:
> Hi,
> 
> today I saw this error in messages:
> 
> : fsync: giving up on dirty
> : 0xc5564110: tag devfs, type VCHR
> : usecount 1, writecount 0, refcount 78 mountedhere 0xc54ef800
> : flags ()
> : v_object 0xc556645c ref 0 pages 1146
> : lock type devfs: EXCL (count 1) by thread 0xc5236a50 (pid 39)
> : dev mirror/gm0s2e.journal
> : GEOM_JOURNAL: Cannot suspend file system /vol0 (error=35).
> 
> Is it something harmful, or is it "normal" behavior? It was in time when 
> generating backup (high disk I/O).
> Gjournal is on top of gmirrored SATA disks.
> 
> mirror/gm0s2d is 2GB journal provider
> mirror/gm0s2e.journal is 380GB data provider

This shouldn't be a problem really.  If these are on SCSI disks, you 
might try increasing the queue depth using camcontrol (see the 'tags' 
command in the camcontrol man page).  You could also try reducing the 
journal flush time (I can't recall the sysctl to set right now - I think 
the default is 10s).

Eric
Permalink | Reply | 1 comment |
headers
Miroslav Lachman | 7 Mar 2008 15:26
Picon

Re: GEOM_JOURNAL: Cannot suspend file system /vol0 (error=35)

Eric Anderson wrote:
> Miroslav Lachman wrote:
> 
>> Hi,
>>
>> today I saw this error in messages:
>>
>> : fsync: giving up on dirty
>> : 0xc5564110: tag devfs, type VCHR
>> : usecount 1, writecount 0, refcount 78 mountedhere 0xc54ef800
>> : flags ()
>> : v_object 0xc556645c ref 0 pages 1146
>> : lock type devfs: EXCL (count 1) by thread 0xc5236a50 (pid 39)
>> : dev mirror/gm0s2e.journal
>> : GEOM_JOURNAL: Cannot suspend file system /vol0 (error=35).
>>
>> Is it something harmful, or is it "normal" behavior? It was in time 
>> when generating backup (high disk I/O).
>> Gjournal is on top of gmirrored SATA disks.
>>
>> mirror/gm0s2d is 2GB journal provider
>> mirror/gm0s2e.journal is 380GB data provider
> 
> 
> 
> This shouldn't be a problem really.  If these are on SCSI disks, you 
> might try increasing the queue depth using camcontrol (see the 'tags' 
> command in the camcontrol man page).  You could also try reducing the 
> journal flush time (I can't recall the sysctl to set right now - I think 
> the default is 10s).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rick C. Petty | 8 Mar 2008 00:00

geom_vinum platform-independent brokenness

Since no one seems to be working on fixing gvinum, I've decided to
investigate and address some problems I have encountered recently.

***

There is an incompatibility in geom_vinum with respect to i386/amd64.
In particular, the following structure (in geom_vinum_var.h) is stored
as-is on each disk (or provider):

	struct gv_hdr {
        	uint64_t        magic;
	#define GV_MAGIC        22322600044678729LL
	#define GV_NOMAGIC      22322600044678990LL

        	int             config_length;
        	struct gv_label label;
	};

The problem is the "struct gv_label" is not aligned properly against the
int.  On i386 and amd64 system, this corresponds to these offsets:

	i386	amd64	field
	----	-----	-----
	0	0	magic
	8	8	config_length
	-	-	from struct gv_label :
	12	16	sysname
	44	48	name (of drive)
	76	80	date_of_birth
	84	96	last_update
(Continue reading)

Permalink | Reply | 4 comments |
headers
Damian Wiest | 8 Mar 2008 03:49
Favicon

Re: geom_vinum platform-independent brokenness

On Fri, Mar 07, 2008 at 05:00:58PM -0600, Rick C. Petty wrote:
> Since no one seems to be working on fixing gvinum, I've decided to
> investigate and address some problems I have encountered recently.
> 
> ***
> 
> There is an incompatibility in geom_vinum with respect to i386/amd64.
> In particular, the following structure (in geom_vinum_var.h) is stored
> as-is on each disk (or provider):
> 
> 	struct gv_hdr {
>         	uint64_t        magic;
> 	#define GV_MAGIC        22322600044678729LL
> 	#define GV_NOMAGIC      22322600044678990LL
> 
>         	int             config_length;
>         	struct gv_label label;
> 	};
> 
> The problem is the "struct gv_label" is not aligned properly against the
> int.  On i386 and amd64 system, this corresponds to these offsets:
> 
> 	i386	amd64	field
> 	----	-----	-----
> 	0	0	magic
> 	8	8	config_length
> 	-	-	from struct gv_label :
> 	12	16	sysname
> 	44	48	name (of drive)
> 	76	80	date_of_birth
(Continue reading)

Permalink | Reply | 3 comments |

Gmane