Re: zfs on geli vs. geli on zfs (via zvol)

[Todd Wasson]

Thanks to both C. P. and Pete for your responses.  Comments inline:

> Case 1.) is probably harmless, because geli would return a
> corrupted sectors' content to zfs... which zfs will likely detect
> because it wouldn't checksum correctly. So zfs will correct it
> out of redundant storage, and write it back through a new
> encryption. BE CAREFUL: don't enable hmac integrity checks
> in geli, as that would prevent geli from returning corrupted
> data and would result in hangs!

Perhaps the hmac integrity checks were related to the lack of reporting of 
problems back to zfs that Pete referred to?  Maybe we need someone with more 
technical experience with the filesystem / disk access infrastructure to weigh 
in, but it still doesn't seem clear to me what the best option is.

> Case 2.) is a bigger problem. If a sector containing vital
> geli metadata (perhaps portions of keys?) gets corrupted,
> and geli had no way to detect and/or correct this (e.g. by
> using redundant sectors on the same .eli volume!), the whole
> .eli, or maybe some stripes out of it, could become useless.
> ZFS couldn't repair this at all... at least not automatically.
> You'll have to MANUALLY reformat the failed .eli device, and
> resilver it from zfs redundant storage later.

This is precisely the kind of thing that made me think about putting zfs 
directly on the disks instead of geli...  This, and other unknown issues that 
could crop up and are out of geli's ability to guard against.

> There may be other failure modes involved as well. I don't know.
> But in most practical day to day uses, with enough redundancy
> and regular backups, a zfs-over-geli should be good enough.

I understand the point here, but I'm specifically thinking about my backup 
server.  As I understand it, part of the purpose of zfs is to be reliable 
enough to run on a backup server itself, given some redundancy as you say.  
Perhaps asking for encryption as well is asking too much (at least, unless zfs 
v30 with zfs-crypto ever gets open-sourced and ported) but I'd really like to 
maintain zfs' stability while also having an option for encryption.

> I wouldn't put {zfs,ufs}-over-geli-over-raw-zpool though, as this
> would involve considerable overhead, IMHO. In this case, I'd
> rather use a gmirror as a backend, as in a setup:
>  {zfs,ufs}-over-geli-over-{gmirror,graid3}
> or something similar. But I've never tried this though.

I understand about the overhead, but I'm interested in using zfs via a zraid to 
avoid using gmirror or graid3, because of the benefits (detection of silent 
corruption, etc.) that you get with a zraid.  I think your suggestion is a 
pretty good one in terms of performance/reliability tradeoff, though.  In my 
specific case I'm more likely to pay a performance cost instead of a 
reliability cost, but only because my server spends most of its time hanging 
around idling, and throughput isn't really an issue.  Thanks regardless, though.


Todd___
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"

HAST + ZFS: no action on drive failure

[Timothy Smith]

First posting here, hopefully I'm doing it right =)

I also posted this to the FreeBSD forum, but I know some hast folks monitor
this list regularly and not so much there, so...

Basically, I'm testing failure scenarios with HAST/ZFS. I got two nodes,
scripted up a bunch of checks and failover actions between the nodes.
Looking good so far, though more complex that I expected. It would be cool
to post it somewher to get some pointers/critiques, but that's another
thing.

Anyway, now I'm just seeing what happens when a drive fails on primary node.
Oddly/sadly, NOTHING!

Hast just keeps on a ticking, and doesn't change the state of the failed
drive, so the zpool has no clue the drive is offline. The
/dev/hast/ remains. The hastd does log some errors to the system
log like this, but nothing more.

messages.0:Jun 30 18:39:59 nas1 hastd[11066]: [ada6] (primary) Unable to
flush activemap to disk: Device not configured.
messages.0:Jun 30 18:39:59 nas1 hastd[11066]: [ada6] (primary) Local request
failed (Device not configured): WRITE(4736512, 512).

So, I guess the question is, "Do I have to script a cronjob to check for
these kinds of errors and then change the hast resource to 'init' or
something to handle this?" Or is there some kind of hastd config setting
that I need to set? What's the SOP for this?

As something related too, when the zpool in FreeBSD does finally notice that
the drive is missing because I have manually changed the hast resource to
INIT (so the /dev/hast/ is gone), my zpool (raidz2) hot spare doesn't
engage, even with "autoreplace=on". The zpool status of the degraded pool
seems to indicate that I should manually replace the failed drive. If that's
the case, it's not really a "hot spare". Does this mean the "FMA Agent"
referred to in the ZFS manual is not implemented in FreeBSD?

thanks!
___
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: UFS SU+J

[Scott Long]

On Jun 30, 2011, at 4:28 AM, Ivan Voras wrote:

> On 29/06/2011 23:03, Mark Saad wrote:
> 
>> The svn sources are here http://svn.freebsd.org/base/projects/suj/8/ .
>> 
>> Why would suj not make it into 8-STABLE ?
> 
> It is a too large patch, and it changes a lot of important, known and
> working code (like softupdates). In other words, it's too risky.
> 

I'm preparing to put it into large-scale deployment at Yahoo on FreeBSD 7.  It 
wasn't ready for production until the latest round of fixes from Jeff and Kirk.

Scott


___
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: Crashes with Promise controller

[Thomas Ronner]

On 6/30/11 8:08 PM, Christian Baer wrote:

Please keep in mind though that I am not the only person out there with
the same error using the same controller (type). I somehow doubt that
all those hits by Google are all caused by power difficulties and the
common controller is pure coincidence.



Just a little 'me too'.

I used to have a system with an Athlon XP 3200+, an ASUS A7V880 
mainboard (iirc) and a Promise SATA150TX4 and a Promise 
SATA300something, both PCI (no PCI-e) cards with 4 SATA ports. I didn't 
encounter system resets, but hard lockups with FreeBSD 7 and 8. No 
kernel messages on the console, everything just hang until I pressed the 
hard reset button.


After about 3 months of testing and frustration I gave up and bought 
another controller.



Regards, Thomas
___
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: Crashes with Promise controller

[Christian Baer]

On 18.06.2011 19:52, Jeremy Chadwick wrote:

Hello Jeremy!

Thanks for your long answer! I'm sorry to have kept you waiting but I
was out of town and turned off all my computers while I was away.

> It may be that the kernel is panic'ing and auto-rebooting before he can
> see the message in question.  I would advocate he put the following
> directives in his kernel configuration and rebuild/reinstall kernel and
> wait for it to happen again.
> 
> # Debugging options
> options   KDB # Enable kernel debugger support
> options   KDB_TRACE   # Print stack trace 
> automatically on panic
> options   DDB # Support DDB
> options   GDB # Support remote GDB
> 
> If after doing this the machine literally reboots rather than panics,
> then that would indicate a mainboard having issues, or power-related
> stuff (keep reading).

I always read the full post if someone takes the time to help me out. :-)

Ok, new kernel compiled and installed. System restarted and running. :-)
I'm guessing that a panic won't show up in the log files, but only on
the console. I have set up a monitor for this machine (normally it
doesn't have one).

I'll try to provoke the little problem as of now and I will get back to
you as soon at I have something.

[power issues]

> I have no proof this is Christian's problem, but it's worth
> considering anyway.

You don't need proof to encourage me to start poking around in a certain
area. Hell, it's pretty hard to give someone proof when only aswering to
a post on a mailing list. :-) Don't feel bad. ;-)

I have to admit that I haven't considered this and when running the
numbers it seems pretty unlikely. The computer has 11 HDs running but
even if we allow each HD 15W, that still isn't really all that much -
not much more than a good graphics card. Apart from the CPU the computer
has no real consumers (not even an optical drive).

Apart from that, the problem doesn't seem to apply when reading from the
drives, only when writing to them. I realize that writing uses a bit
more power than reading but the "surge of writing" shouldn't be such a
big deal that it could make the difference in my case. Or could it?

Apart from that, HDs use much more power when spinning up. This doesn't
seem to pose a problem for the power supply. I have seen no troubles
when starting the system.

What got me thinking was that I don't know how many of the drives are
actually connected by a single rail. I didn't really pay much attention
to that when I connected them but they should be spread somewhat just
the same, mainly because the cables are just too short to connect
everything to a single rail without *really* going out of you way to do it.

Once I have a panic screen to show you I will grab a second power supply
and start some tests.

Please keep in mind though that I am not the only person out there with
the same error using the same controller (type). I somehow doubt that
all those hits by Google are all caused by power difficulties and the
common controller is pure coincidence.

Best regards,
Chris

___
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: Crashes with Promise controller

[Thomas Ronner]

On 6/30/11 7:31 PM, Christian Baer wrote:

As far as I can tell so far there isn't any realy kernel panik. But the
machine resets alright. All I can find in /var/log/messages is what I
have already written. :-(

A serial console is easy enough to set up on a Sun for example, but in
this case, I am running a simple AthlonXP, which has nothing for that
sort of help. I would need a special card for that and those cose quite
a bit. :-(


You can use a USB to serial converter. They cost around $20. I don't 
know which one to choose; I've never used one on FreeBSD so hopefully 
someone else can fill me in here.



Regards,
Thomas
___
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: Crashes with Promise controller

[Christian Baer]

On 18.06.2011 18:49, Stefan Bethke wrote:

>> I have to slightly explain the word "crash" here: I don't actually
>> have to hard reset the system myself. My box just does a reboot by
>> itself. No filesystem is unmounted cleanly and because the machine
>> isn't really new and powerful fsck takes pretty long.
> 
> I can't help you with your controllers, but anyone in a position to
> help will likely want to know if the box simply resets, or if the
> kernel panics.  And if there are going to be any patches, you most
> certainly will want to get familiar with the debugger to help try
> stuff out.  The handbook has information on how to enable crash dumps
> and getting the kernel debugger going.  If you haven't done so
> already, try and get a serial console going, it helps tremendously to
> be able to cut&paste debugger info instead of trying to hand
> transcribe it.

As far as I can tell so far there isn't any realy kernel panik. But the
machine resets alright. All I can find in /var/log/messages is what I
have already written. :-(

A serial console is easy enough to set up on a Sun for example, but in
this case, I am running a simple AthlonXP, which has nothing for that
sort of help. I would need a special card for that and those cose quite
a bit. :-(

Regards,
Chris

___
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: Dell PowerEdge 1950: MPT0 doesn't recogniz hard drive > 2TB

[Joshua Boyd]

2011/6/30 O. Hartmann 

> It's a pitty.
>

Indeed, it is. I have 3 1068s for 45 bays, I'm gonna have to buy new cards
:(.

-- 
Joshua Boyd

E-mail: boy...@jbip.net
http://www.jbip.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: kern/143370: splash_txt ASCII splash screen module

[Vitaly Magerya]

Antony Mawer wrote:
> Not sure if this is the right place to post it -- about 6 years ago I
> put together a module which displays an ASCII splash screen on boot
> (rather than the graphical splash_pcx and splash_bmp modules).

As a user, I think this is rather cool; at least it is more useful for
me than bmp/pcx splash modules, as I don't want to load vesa.

Hm... Can you center the image if the display size is other than 80x25?
Or try to temporarily change the video mode? It looks a bit misplaced in
80x50.

Also, this would be 2x as cool if you could animate the splash. For
example, if the supplied bitmap is 80x50, you could treat that as 2
frames, and cycle through them periodically (I assume that splash
modules work the same way as saved modules do: the main function is
called a few times per second, so you can update the screen there).

BTW, in txt_init you currently check for data_size <= 0; you should also
check for data_size < BIN_IMAGE_WIDTH * BIN_IMAGE_HEIGHT * 2, since if
the bitmap is smaller, you'll draw garbage on the screen.

> I have uploaded two sample boot splash screens at
> http://www.mawer.org/freebsd/freebsd1.bin and
> http://www.mawer.org/freebsd/freebsd2.bin . The files can be produced
> using TheDraw and saving in its Binary file format, which consists of
> a sequence of 2 byte pairs. The first byte in a pair is the character
> to draw on the screen, and the second is the colour/display attributes
> to draw the character with.

As a side note, these images can also be made from video buffer dumps
that vidcontrol produces like this:

vidcontrol -p < /dev/ttyv0 | tail -c +13 > screenshot.bin

(Substitute ttyv0 for the tty you want to take a picture of; the tty
should be in 80x25 mode).
___
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: UFS SU+J

[Ivan Voras]

On 29/06/2011 23:03, Mark Saad wrote:

> The svn sources are here http://svn.freebsd.org/base/projects/suj/8/ .
> 
> Why would suj not make it into 8-STABLE ?

It is a too large patch, and it changes a lot of important, known and
working code (like softupdates). In other words, it's too risky.

___
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: Dell PowerEdge 1950: MPT0 doesn't recogniz hard drive > 2TB

[O. Hartmann]

On 06/29/11 15:57, Joshua Boyd wrote:

2011/6/29 O. Hartmann mailto:ohart...@zedat.fu-berlin.de>>

Questions:
a) Is this an issue of FreeBSD 8.2-STABLE or is it a firmware/BIOS
issue which can be solved?


Hi Oliver,

Neither, unfortunately. The 1068E based cards do not support drives over
2TB. See here:

http://kb.lsi.com/KnowledgebaseArticle16399.aspx

--
Joshua Boyd

E-mail: boy...@jbip.net 
http://www.jbip.net


Hello Joshua.
Thanks for the fast response.
Yes, you're right. I revealed by several postings in the net that the 
controller in question is not capable of handling disks > 2TB. It's a pitty.


Oliver
___
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"