Re: Any success stories for HAST + ZFS?

[Pete French]

> Yes, you may hit it only on hast devices creation. The workaround is to avoid
> using 'hastctl role primary all', start providers one by one instead.

Interesting to note that I just hit a lockup in hast (the discs froze
up - could not run hastctl or zpool import, and could not kill
them). I have two hast devices instead of one, but I am starting them
individually instead of  using 'all'. The copde includes all the latest
patches which have gone into STABLE over the last few days, none of which
look particularly controversial!

I havent tried your atch yet, nor been able to reporduce the lockup, but
thought you might be interested to know that I also had problems with
multiple providers.

cheers,

-pete.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Any success stories for HAST + ZFS?

[Pete French]

> The other 5% of the time, the hastd crashes occurred either when
> importing the ZFS pool, or when running multiple parallel rsyncs to
> the pool.  hastd was always shown as the last running process in the
> backtrace onscreen.

This is what I am seeing - did you manage to reproduce this with the patch,
or does it fix the issue for you ? Am doing more test now, with only a single
hast device to see if it is stable. Am Ok to run without mirroring across
hast devices for now, but wouldnt like to do so long term!

-pete.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Constant rebooting after power loss

[Marko Lerota]

Today one of my home servers lost power two times in a short
period of time. After that, the system just couldn't get up. 
Background checks couldn't get started. The messages was how 
/ /tmp /var etc...had to much errors. And at the end, always 
got this: "automatic reboot will start in 15sec".

I went to single user mode, and ran FSCK manually. That solved 
the problem. But the server was down for 2 hours.

This is not the first time that I had to do this. Every now 
and then I have seen this on BSD servers without UPS. 

My question is:

Would it happen if I had ZFS as a file system on all partitions
including root? 

The setup was FreeBSD 8.1, with two disks in raid 1 with gmirror. 

-- 
Marko Lerota
Sent from my Gnus Mailer
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Constant rebooting after power loss

[George Kontostanos]

Not with the same behavior and it depends on what your server is doing at
the time of the power interruption. In most cases you wouldn't see anything
but ZFS is not the solution to your problem. ZFS is not designed to replace
the needs of a UPS.

On Fri, Apr 1, 2011 at 2:27 PM, Marko Lerota  wrote:

> Today one of my home servers lost power two times in a short
> period of time. After that, the system just couldn't get up.
> Background checks couldn't get started. The messages was how
> / /tmp /var etc...had to much errors. And at the end, always
> got this: "automatic reboot will start in 15sec".
>
> I went to single user mode, and ran FSCK manually. That solved
> the problem. But the server was down for 2 hours.
>
> This is not the first time that I had to do this. Every now
> and then I have seen this on BSD servers without UPS.
>
> My question is:
>
> Would it happen if I had ZFS as a file system on all partitions
> including root?
>
> The setup was FreeBSD 8.1, with two disks in raid 1 with gmirror.
>
> --
> Marko Lerota
> Sent from my Gnus Mailer
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>



-- 
George Kontostanos
aisecure.net 
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Any success stories for HAST + ZFS?

[Mikolaj Golub]

On Fri, 01 Apr 2011 11:40:11 +0100 Pete French wrote:

 >> Yes, you may hit it only on hast devices creation. The workaround is to 
 >> avoid
 >> using 'hastctl role primary all', start providers one by one instead.

 PF> Interesting to note that I just hit a lockup in hast (the discs froze
 PF> up - could not run hastctl or zpool import, and could not kill
 PF> them). I have two hast devices instead of one, but I am starting them
 PF> individually instead of  using 'all'. The copde includes all the latest
 PF> patches which have gone into STABLE over the last few days, none of which
 PF> look particularly controversial!

 PF> I havent tried your atch yet, nor been able to reporduce the lockup, but
 PF> thought you might be interested to know that I also had problems with
 PF> multiple providers.

This looks like a different problem. If you have this again please provide the
output of 'procstat -kka'.

-- 
Mikolaj Golub
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Any success stories for HAST + ZFS?

[Pete French]

> This looks like a different problem. If you have this again please provide the
> output of 'procstat -kka'.

Will do...

-pete.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Constant rebooting after power loss

[Marat N.Afanasyev]

Marko Lerota wrote:

Today one of my home servers lost power two times in a short
period of time. After that, the system just couldn't get up.
Background checks couldn't get started. The messages was how
/ /tmp /var etc...had to much errors. And at the end, always
got this: "automatic reboot will start in 15sec".

I went to single user mode, and ran FSCK manually. That solved
the problem. But the server was down for 2 hours.

This is not the first time that I had to do this. Every now
and then I have seen this on BSD servers without UPS.

My question is:

Would it happen if I had ZFS as a file system on all partitions
including root?

The setup was FreeBSD 8.1, with two disks in raid 1 with gmirror.

I'm afraid that in case of sequential power loss you will be faced with 
broken filesystems regardless of filesystem you're using. and I suppose 
that data on your servers costs, at least, ten times more than any UPS 
that should safely shut down your server in case of black out.


--
С уважением, Марат Афанасьев

Re: Constant rebooting after power loss

[Marko Lerota]

George Kontostanos  writes:

> Not with the same behavior and it depends on what your server is doing at
> the time of the power interruption. 

It was in stage of booting after first power loss. 

> but ZFS is not the solution to your problem. ZFS is not designed to replace
> the needs of a UPS.

I'm just asking if this wouldn't happen if I used ZFS. I read that ZFS
don't need fsck because the files are always consistent on filesystem 
regardless of power loses. That the corruption can occur only if disks
are damaged. But not when power goes down. I'm not planing to buy UPS 
for home use. 

-- 
Marko Lerota
Sent from my Gnus Mailer
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Any success stories for HAST + ZFS?

[Freddie Cash]

On Fri, Apr 1, 2011 at 4:22 AM, Pete French  wrote:
>> The other 5% of the time, the hastd crashes occurred either when
>> importing the ZFS pool, or when running multiple parallel rsyncs to
>> the pool.  hastd was always shown as the last running process in the
>> backtrace onscreen.
>
> This is what I am seeing - did you manage to reproduce this with the patch,
> or does it fix the issue for you ? Am doing more test now, with only a single
> hast device to see if it is stable. Am Ok to run without mirroring across
> hast devices for now, but wouldnt like to do so long term!

I have not been able to crash or hang the box since applying Mikolaj's patch.

I've tried the following:
  - destroy pool
  - create pool
  - destroy hast providers
  - create hast providers
  - switch from master to slave via hastctl using "role secondary all"
  - switch from slave to master via hastctl using "role primary all"
  - switch roles via hast-carp-switch which does one provider per second
  - import/export pool

I've been running 6 parallel rsyncs for the past 48 hours, getting a
consistent 200 Mbps of transfers, with just under 2 TB of deduped data
in the pool, without any lockups.

So far, so good.
-- 
Freddie Cash
fjwc...@gmail.com
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Best way to switch from Linux to BSD

[Zoran Kolic]

> I've been using Opera forever. It as an old and proven browser and it runs
> natively on FreeBSD. You can have the Linux flash plugin attached to it and
> still run the native FreeBSD version. It also supports html5.

I use Conkeror on both desktop and laptop and simply cannot
imagine to go back to .
Just wonna stress how my nodes run no more than 10 processes
at the boot time and how that differs from whatever os I en-
countered so far. As almost all posters on this topic I do not
care for a dime if someone finds freebsd hard to configure to
suit. It is part of the game and fun itself.
Best regards

 Zoran

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Constant rebooting after power loss

[Marat N.Afanasyev]

Marko Lerota wrote:

George Kontostanos  writes:


Not with the same behavior and it depends on what your server is doing at
the time of the power interruption.


It was in stage of booting after first power loss.


but ZFS is not the solution to your problem. ZFS is not designed to replace
the needs of a UPS.


I'm just asking if this wouldn't happen if I used ZFS. I read that ZFS
don't need fsck because the files are always consistent on filesystem
regardless of power loses. That the corruption can occur only if disks
are damaged. But not when power goes down. I'm not planing to buy UPS
for home use.

to ensure consistency you should turn off physical drive caches, and 
degrade performance significantly, sometimes up to 1000x. if this is 
what you want, you may use either zfs or sync ufs. in such case you may 
be almost sure that your filesystems are consistent. but if you use 
drive's cache, then without UPS you will face data loss and vanished 
filesystem earlier or later


--
С уважением, Марат Афанасьев

Re: Constant rebooting after power loss

[Stefan `Sec` Zehl]

Hi,

On Fri, Apr 01, 2011 at 13:27 +0200, Marko Lerota wrote:
> Today one of my home servers lost power two times in a short
> period of time. After that, the system just couldn't get up. 
> Background checks couldn't get started. The messages was how 
> / /tmp /var etc...had to much errors. And at the end, always 
> got this: "automatic reboot will start in 15sec".
> 
> I went to single user mode, and ran FSCK manually. That solved 
> the problem. But the server was down for 2 hours.

If you want to get rid of the reboot loop, set:

background_fsck="NO"

Then it will either come up, or ask for help if anything fails.

If you absolutely want the server to come up, you can set this

fsck_y_enable="YES"

Assuming you're in the habit of answering "yes" to fsck's questions,
this will do it automatically in case of problems.

(Both settings are for /etc/rc.conf, of course)

CU,
Sec
-- 
One of the strongest advantages of plain-text email is
that people cannot use the typesetting features they want.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Constant rebooting after power loss

[Bob Willcox]

On Fri, Apr 01, 2011 at 03:29:39PM +0200, Marko Lerota wrote:
> George Kontostanos  writes:
> 
> > Not with the same behavior and it depends on what your server is doing at
> > the time of the power interruption. 
> 
> It was in stage of booting after first power loss. 
> 
> > but ZFS is not the solution to your problem. ZFS is not designed to replace
> > the needs of a UPS.
> 
> I'm just asking if this wouldn't happen if I used ZFS. I read that ZFS
> don't need fsck because the files are always consistent on filesystem 
> regardless of power loses. That the corruption can occur only if disks
> are damaged. But not when power goes down. I'm not planing to buy UPS 
> for home use. 

I really don't know much about ZFS, but I do know about disks (I work on SAS
device drivers for AIX and deal with lots of disks); and I doubt that any
filesystem is going to be immune to sudden power failures when writing to a
disk. At least I wouldn't trust them. If you care about the integrity of your
data, I would reconsider your plans about the UPS.

-- 
Bob Willcox  Trying to explain things to people who already know
b...@immure.com   everything is like trying to teach a bear to dance;
Austin, TX   it's useless, and it annoys the bear.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Best way to switch from Linux to BSD

[Nikola Pavlović]

On Tue, Mar 29, 2011 at 07:56:09PM +0200, Christian Walther wrote:
> 2011/3/29 Nikola Pavlović :
> > As far as eye candy goes, I assure you KDE Plasma bells and whistles
> > (compositing etc.) work just fine even on a 9 year old Pentium 4 w/ 1GB
> > RAM and an NVidia GeForce 6200.  I'm actually amazed how well it works,
> > it's faster than XFCE on Slackware was...  Weird stuff. O.o (I'm not
> > really implying anything, just noticing something I didn't expect.)
> 
> Nice. :)
> Maybe it's time to give KDE4 another try.

I haven't used KDE in years, but a few months ago I switched to FreeBSD
on my desktop and since there's nothing but KDE and Gnome on the
installation DVD, I figured it wouldn't hurt anything if I tried KDE (I
really don't like Gnome :).  And whaddya know, I ended up liking it, it
feels comfortable.  I'm certainly not a fan of the whole Akonadi,
Nepomuk, Telepathy, etc. hysteria, but as long as I don't need to run 
and use it I'm happy to ignore it and just use features I need/want.

> Its' graphics performance
> seems be to have been improved with Release 4.2 anyway (at least I've
> been told), and my last test was with an early 4.0 release. My wifes'
> laptop is on Linux for some time now, and I already noticed that
> nspluginwrapper + flash plugin are stable even after updates.

My experience with Flash on FreeBSD has so far been just fine.  Sure, it
crashes and coredumps often, but when it does I just reload the page
and/or "pkill npviewer" and everything's fine.  In fact, I had more
trouble with it on Linux: after watching a lot of videos or after
leaving a page w/ a video loaded for a few hours it would stop working
and Firefox would have to be restarted (at least that's the only
solution I found).

That said, I really go out of my way to avoid Flash, and when I need it
for watching videos I tend to use tools that stream flv through Mplayer,
for example multimedia/youtube-viewer, and others have mentioned
multimedia/minitube, multimedia/cclive and multimedia/quvi.  In fact I
prefer that method to playing it in a browser, but I'm the kind of
person who thinks www/surfraw is better than doing a search in a browser
directly. ;)


-- 
An authority is a person who can tell you more about something than you
really care to know.

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Constant rebooting after power loss

[Clayton Milos]

On Fri, Apr 01, 2011 at 03:29:39PM +0200, Marko Lerota wrote:

George Kontostanos  writes:

> Not with the same behavior and it depends on what your server is doing 
> at

> the time of the power interruption.

It was in stage of booting after first power loss.

> but ZFS is not the solution to your problem. ZFS is not designed to 
> replace

> the needs of a UPS.

I'm just asking if this wouldn't happen if I used ZFS. I read that ZFS
don't need fsck because the files are always consistent on filesystem
regardless of power loses. That the corruption can occur only if disks
are damaged. But not when power goes down. I'm not planing to buy UPS
for home use.


I really don't know much about ZFS, but I do know about disks (I work on 
SAS

device drivers for AIX and deal with lots of disks); and I doubt that any
filesystem is going to be immune to sudden power failures when writing to 
a
disk. At least I wouldn't trust them. If you care about the integrity of 
your

data, I would reconsider your plans about the UPS.

--
Bob Willcox  Trying to explain things to people who already 
know
b...@immure.com   everything is like trying to teach a bear to 
dance;

Austin, TX   it's useless, and it annoys the bear.


I used to live in Sotuh Africa where the power gets bad at times. A UPS was 
a requirement for me to get my work done uninterrupted. Small UPS units are 
not expensive nowadays and it will protect the power supplies from brownouts 
and spikes as well. You will seldom make as good a small investment as a 
UPS.


If you are really anti-UPS for some reason then at least do what Stefan 
suggested or go into the BIOS and set the motherboard's power state after AC 
failure to OFF. This means you will have to press a button to power it on 
again which should be when the power is stable again.


Honestly though, if the power is as bad as it seems where you are I'm 
surprised you haven't bought a UPS already. You can get them at 50 Euro for 
a small one. It will pay for iself in hardware cost alone. I've had power 
spikes taking out PSU's and hard drives before.


-Clay 


___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Constant rebooting after power loss

[Chris H]

On Fri, April 1, 2011 6:29 am, Marko Lerota wrote:
> George Kontostanos  writes:
>
>
>> Not with the same behavior and it depends on what your server is doing at
>> the time of the power interruption.
>
> It was in stage of booting after first power loss.
>
>
>> but ZFS is not the solution to your problem. ZFS is not designed to replace
>> the needs of a UPS.
>
>  I read that ZFS don't need fsck because the files are always consistent on
filesystem regardless
> of power loses. That the corruption can occur only if disks are damaged. But 
> not
> when power goes down.

Complete nonsense. The information you read was false.

>
> --
> Marko Lerota
> Sent from my Gnus Mailer
> ___
> freebsd-stable@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
>


-- 

If only Western Electric had found a way to offer
binary licenses for the UNIX system back in 1974,
the UNIX system would be running on all PC's today
rather than DOS/Windows. --en UNIX veritas!



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Constant rebooting after power loss

[Adam Vande More]

On Fri, Apr 1, 2011 at 12:02 PM, Chris H  wrote:

> On Fri, April 1, 2011 6:29 am, Marko Lerota wrote:
> >  I read that ZFS don't need fsck because the files are always consistent
> on
> filesystem regardless
> > of power loses. That the corruption can occur only if disks are damaged.
> But not
> > when power goes down.
>
> Complete nonsense. The information you read was false.
>

 No, it's really not.  ZFS's lack of recovery tools at least in the
beginning were basically non existent.   This is because ZFS uses a COW
model with an atomic data management unit design which by it's nature
addresses thing like fsck, and sudden power loss.  However, things outside
of a FS's control still allow corrution to happen so as UPS is just as
important with ZFS as your traditional FS.  Perhaps more important because
the difficulty from recovering from some types of pool corruption.

-- 
Adam Vande More
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: geli(4) memory leak

[Victor Balada Diaz]

On Sat, Mar 26, 2011 at 01:33:48AM +0100, Victor Balada Diaz wrote:
> Hello,
> 
> I'm trying to setup a new geli disk and i'm seeing what looks like a memory 
> leak.
> After initializing the device i've tried to do the dd command from /dev/random
> like this one:
> 
> dd if=/dev/random of=/dev/da0p1.eli  bs=1m
> 

Hello again,

I've found the cause of the memory leak and i attach a patch to fix it. I hope
the patch is good enough to get committed or at least helps someone made a 
better
patch and commit it. Patched file is src/sys/geom/eli/g_eli.c

The problem happens when you're using data integrity verification and you need
to write more than MAXPHYS. If you look at g_eli_integrity.c:314 you'll 
see that geli creates a second request to write all that's needed.

Each of the request get the callback to g_eli_write_done once they're done. The 
  
first request will get up to g_eli.c:209 and find that there are still requests
pending so instead of calling g_io_deliver to notify it's written data, it just
returns and waits until all requests are done to say everything's OK. The 
problem
is that once you return, you're leaking this g_bio. You can see with vmstat -z 
how
g_bio increases and never releases memory.

I just destroy the current bio before returning and that prevents the memory 
leak.

Regards.
Victor.
-- 
La prueba más fehaciente de que existe vida inteligente en otros
planetas, es que no han intentado contactar con nosotros. 
--- g_eli.c	2010-12-21 18:09:25.0 +0100
+++ g_eli.c.patched	2011-04-01 19:16:41.0 +0200
@@ -206,8 +206,10 @@
 	 * Do we have all sectors already?
 	 */
 	pbp->bio_inbed++;
-	if (pbp->bio_inbed < pbp->bio_children)
+	if (pbp->bio_inbed < pbp->bio_children) {
+	g_destroy_bio(bp);
 		return;
+	}
 	free(pbp->bio_driver2, M_ELI);
 	pbp->bio_driver2 = NULL;
 	if (pbp->bio_error != 0) {
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Constant rebooting after power loss

[Christian Walther]

On 1 April 2011 19:38, Adam Vande More  wrote:
> On Fri, Apr 1, 2011 at 12:02 PM, Chris H  wrote:
>
>> On Fri, April 1, 2011 6:29 am, Marko Lerota wrote:
>> >  I read that ZFS don't need fsck because the files are always consistent
>> on
>> filesystem regardless
>> > of power loses. That the corruption can occur only if disks are damaged.
>> But not
>> > when power goes down.
>>
>> Complete nonsense. The information you read was false.
>>
>
>  No, it's really not.  ZFS's lack of recovery tools at least in the
> beginning were basically non existent.   This is because ZFS uses a COW
> model with an atomic data management unit design which by it's nature
> addresses thing like fsck, and sudden power loss.

Indeed.
By copy on write and its' b-tree ZFS ensures consistency, however,
this does not mean that there's no data loss. Writes are done in a
transaction group, including an updated version of the b-tree. Only if
all the new information has been written successfully the new b-tree
"is tagged as valid" and becomes active. (Which is the reason why you
can't rm files in a full pool.)
If there's a power failure during a write ZFS recovers automatically
during the mount (or zpool import, not sure on this one) _by deleting
the inconsistent data_ and thus reverting to the last known state.
Additionally, a transaction group may consist of several writes that
reach a total size (I think 128Kb per default). If there are small and
slow writes (e.g.to a Logfie) these are cached up to 30 seconds. If a
power failure or any other kind of discruptive failure happens you'll
loose all the information cached.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Constant rebooting after power loss

[Doug Barton]

On 4/1/2011 8:47 AM, Stefan `Sec` Zehl wrote:

If you want to get rid of the reboot loop, set:

background_fsck="NO"

Then it will either come up, or ask for help if anything fails.

If you absolutely want the server to come up, you can set this

fsck_y_enable="YES"


+1

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: geli(4) memory leak

[Mikolaj Golub]

On Fri, 1 Apr 2011 19:43:54 +0200 Victor Balada Diaz wrote:

 VBD> On Sat, Mar 26, 2011 at 01:33:48AM +0100, Victor Balada Diaz wrote:
 >> Hello,
 >> 
 >> I'm trying to setup a new geli disk and i'm seeing what looks like a memory 
 >> leak.
 >> After initializing the device i've tried to do the dd command from 
 >> /dev/random
 >> like this one:
 >> 
 >> dd if=/dev/random of=/dev/da0p1.eli  bs=1m
 >> 

 VBD> Hello again,

 VBD> I've found the cause of the memory leak and i attach a patch to fix it. I 
hope
 VBD> the patch is good enough to get committed or at least helps someone made 
a better
 VBD> patch and commit it. Patched file is src/sys/geom/eli/g_eli.c

 VBD> The problem happens when you're using data integrity verification and you 
need
 VBD> to write more than MAXPHYS. If you look at g_eli_integrity.c:314 you'll 
 VBD> see that geli creates a second request to write all that's needed.

 VBD> Each of the request get the callback to g_eli_write_done once they're 
done. The   
 VBD> first request will get up to g_eli.c:209 and find that there are still 
requests
 VBD> pending so instead of calling g_io_deliver to notify it's written data, 
it just
 VBD> returns and waits until all requests are done to say everything's OK. The 
problem
 VBD> is that once you return, you're leaking this g_bio. You can see with 
vmstat -z how
 VBD> g_bio increases and never releases memory.

 VBD> I just destroy the current bio before returning and that prevents the 
memory leak.

For me your patch look correct. But the same issue is for read :-). Also, to
avoid the leak I think we can just do g_destroy_bio() before "all sectors"
check. See the attached patch (had some testing).

-- 
Mikolaj Golub

Index: sys/geom/eli/g_eli.c
===
--- sys/geom/eli/g_eli.c	(revision 220168)
+++ sys/geom/eli/g_eli.c	(working copy)
@@ -160,13 +160,13 @@ g_eli_read_done(struct bio *bp)
 	pbp = bp->bio_parent;
 	if (pbp->bio_error == 0)
 		pbp->bio_error = bp->bio_error;
+	g_destroy_bio(bp);
 	/*
 	 * Do we have all sectors already?
 	 */
 	pbp->bio_inbed++;
 	if (pbp->bio_inbed < pbp->bio_children)
 		return;
-	g_destroy_bio(bp);
 	sc = pbp->bio_to->geom->softc;
 	if (pbp->bio_error != 0) {
 		G_ELI_LOGREQ(0, pbp, "%s() failed", __func__);
@@ -202,6 +202,7 @@ g_eli_write_done(struct bio *bp)
 		if (bp->bio_error != 0)
 			pbp->bio_error = bp->bio_error;
 	}
+	g_destroy_bio(bp);
 	/*
 	 * Do we have all sectors already?
 	 */
@@ -215,7 +216,6 @@ g_eli_write_done(struct bio *bp)
 		pbp->bio_error);
 		pbp->bio_completed = 0;
 	}
-	g_destroy_bio(bp);
 	/*
 	 * Write is finished, send it up.
 	 */
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Constant rebooting after power loss

[Chris H]

On Fri, April 1, 2011 10:38 am, Adam Vande More wrote:
> On Fri, Apr 1, 2011 at 12:02 PM, Chris H  wrote:
>
>
>> On Fri, April 1, 2011 6:29 am, Marko Lerota wrote:
>>
>>> I read that ZFS don't need fsck because the files are always consistent
>>>
>> on filesystem regardless
>>> of power loses. That the corruption can occur only if disks are damaged.
>> But not
>>
>>> when power goes down.
>>
>> Complete nonsense. The information you read was false.
>>
>>
>
> No, it's really not.  ZFS's lack of recovery tools at least in the
> beginning were basically non existent.   This is because ZFS uses a COW model
> with an atomic data management unit design which by it's nature addresses 
> thing
> like fsck, and sudden power loss.  However, things outside of a FS's control
> still allow corrution to happen so as UPS is just as important with ZFS as 
> your
> traditional FS.  Perhaps more important because the difficulty from recovering
> from some types of pool corruption.
>
Greetings,
 Not to sound disagreeable, but
if I interrupt the power during a disk write, no amount of ZFS will insure that
the hardware completes it's write without electricity. Nor will any amount of
ZFS prevent data corruption as a result of that interrupted write.


> --
> Adam Vande More
>
>


-- 

If only Western Electric had found a way to offer
binary licenses for the UNIX system back in 1974,
the UNIX system would be running on all PC's today
rather than DOS/Windows. --en UNIX veritas!



___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Constant rebooting after power loss

[Adam Vande More]

On Fri, Apr 1, 2011 at 4:21 PM, Chris H  wrote:

> >
> Greetings,
>  Not to sound disagreeable, but
> if I interrupt the power during a disk write, no amount of ZFS will insure
> that
> the hardware completes it's write without electricity. Nor will any amount
> of
> ZFS prevent data corruption as a result of that interrupted write.
>

As already stated, if the write doesn't complete, the transaction group is
rolled back to the last consistent state, so no corruption.  There is plenty
of literature of subject of how ZFS works internally to insure this:

http://www.sun.com/bigadmin/features/articles/zfs_part1.scalable.jsp

ZFS's capabilities may seem contrary to your opinion, but properly
implemented it does exactly what you say it cannot do.

-- 
Adam Vande More
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Re: Constant rebooting after power loss

[Matthew Dillon]

The core of the issue here comes down to two things:

First, a power loss to the drive will cause the drive's dirty write cache
to be lost, that data will not make it to disk.  Nor do you really want
to turn of write caching on the physical drive.  Well, you CAN turn it
off, but if you do performance will become so bad that there's no point.
So turning off the write caching is really a non-starter.

The solution to this first item is for the OS/filesystem to issue a
disk flush command to the drive at appropriate times.  If I recall the
ZFS implementation in FreeBSD *DOES* do this for transaction groups,
which guarantees that a prior transaction group is fully synced before
a new ones starts running (HAMMER in DragonFly also does this).
(Just getting an 'ack' from the write transaction over the SATA bus only
means the data made it to the drive's cache, not that it made it to
the platter).

I'm not sure about UFS vis-a-vie the recent UFS logging features...
it might be an option but I don't know if it is a default.  Perhaps
someone can comment on that.

One last note here.  Many modern drives have very large ram caches.
OCZ's SSDs have something like 256MB write caches and many modern HDs
now come with 32MB and 64MB caches.  Aged drives with lots of relocated
sectors and bit errors can also take a very long time to perform writes
on certain sectors.  So these large caches take time to drain and one
can't really assume that an acknowledged write to disk will actually
make it to the disk under adverse circumstances any more.  All sorts
of bad things can happen.

Finally, the drives don't order their writes to the platter (you can
set a bit to tell them to, but like many similar bits in the past there
is no real guarantee that the drives will honor it).  So if two
transactions do not have a disk flush command inbetween them it is
possible for data from the second transaction to commit to the platter
before all the data from the first transaction commits to the platter.
Or worse, for the non-transactional data to update out of order relative
to the transactional data which was supposed to commit first.

Hence IMHO the OS/filesystem must use the disk flush command in such
situations for good reliability.

--

The second problem is that a physical loss of power to the drive can
cause the drive to physically lose one or more sectors, and can even
effectively destroy the drive (even with the fancy auto-park)... if the
drive happens to be in the middle of a track write-back when power is
lost it is possible to lose far more than a single sector, including
sectors unrelated to recent filesystem operations.

The only solution to #2 is to make sure your machines (or at least the
drives if they happen to be in external enclosures) are connected to
a UPS and that the machines are communicating with the UPS via
something like the "apcupsd" port.  AND also that you test to make
sure the machines properly shut themselves down when AC is lost before
the UPS itself runs out of battery time.  After all, a UPS won't help
if the machines don't at least idle their drives before power is lost!!!

I learned this lesson the hard way about 3 years ago.  I had something
like a dozen drives in two raid arrays doing heavy write activity and
lost physical power and several of the drives were totally destroyed,
with thousands of sector errors.  Not just one or two... thousands.

(It is unclear how SSDs react to physical loss of power during heavy
writing activity.  Theoretically while they will certainly lose their
write cache they shouldn't wind up with any read errors).

-Matt

___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"