-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 13 Jun 2009 01:07+0300, Dan Naumov wrote:
Begin Installation screen: The screen states that in order to do a
manual installation SNIP login as root, and follow the instructions
given in the file /README. There is no indication regarding
On Sat, Jun 13, 2009 at 3:56 PM, Dan Naumovdan.nau...@gmail.com wrote:
Which Wiki do you want me to contribute this to?
http://wiki.freebsd.org/FreeBSD/BSDInstaller2009 or
http://wiki.bsdinstaller.org/wikka.php?wakka=BSDInstaller ? Whichever
it is, I am not that experienced with editing Wikis,
Which Wiki do you want me to contribute this to?
http://wiki.freebsd.org/FreeBSD/BSDInstaller2009 or
http://wiki.bsdinstaller.org/wikka.php?wakka=BSDInstaller ? Whichever
it is, I am not that experienced with editing Wikis, so perhaps you
could create the needed sections/subsections for usability
As promised, I took a go at this new BSDInstaller, I wrote down some
of my thoughts. Since I don't know if this is the kind of feedback you
are looking for, here is just a part of it. As you can probably guess
from it, I deal with usability issues in software applications a lot,
hence my point of
sth...@nethelp.no writes:
I've had several cases that needed manual fsck. After I turned off
background fsck, the problems stopped. These days background_fsck=NO
is a standard part of my rc.conf.
Hear, hear.
DES
--
Dag-Erling Smørgrav - d...@des.no
On Wed, 10 Jun 2009, Dag-Erling Sm?rgrav wrote:
DS sth...@nethelp.no writes:
DS I've had several cases that needed manual fsck. After I turned off
DS background fsck, the problems stopped. These days background_fsck=NO
DS is a standard part of my rc.conf.
DS
DS Hear, hear.
Well, I can see at
to be more precise): inappropriate time of file system lock on snapshot
creation. On not-too-big 300G ufs2 not-too-heavy loaded snapshot creation time
is 20+ minutes, and 5+ from that file system blocked even on reads. This looks
unacceptable for me for any real use.
that's why i disable it.
And things like these are amongst the reasons why I want to see newer
options be presented and offered to the user during installation
process. Default installation options (and the ONLY options presented
by sysinstall) that result in enormous snapshot creation times and
long fsck times are just
during installation process as well gives these newer options
(UFS2+GJournal and ZFS in this case) a better exposure, resulting in
more testing, resulting in these new features getting their quirks
ironed out faster and resulting in these new features getting the
truly tested and proven by time
On Tue, Jun 9, 2009 at 12:42 PM, Dan Naumovdan.nau...@gmail.com wrote:
Hello list
Let me preface this by saying that I do not have coding
knowledge/experience, but I am willing to donate my time to help test
things if somebody is already working on this. Hopefully, this will
prevent most of
Quoting Dmitry Morozovsky ma...@rinet.ru:
Well, I can see at least one rather big problem with bgfsck (or with
snapshots to be more precise): inappropriate time of file system
lock on snapshot creation. On not-too-big 300G ufs2 not-too-heavy
loaded snapshot creation time is 20+ minutes,
Hello list
Let me preface this by saying that I do not have coding
knowledge/experience, but I am willing to donate my time to help test
things if somebody is already working on this. Hopefully, this will
prevent most of the potential feel free to submit patches responses
:)
Is there any work
Is there any work going on to make sysinstall recognize and abe able
to create and work with GJOURNAL and ZFS? In the days of 1,5-2,0
terabyte harddrives, UFS2 + SoftUpdates simply doesn't cut it anymore,
UFS2+SoftUpdates works fine on properly configured UFS2 - and very fast.
Why you need
UFS2+SoftUpdates works fine on properly configured UFS2 - and very fast.
Yes, UFS2+SoftUpdates is very fast, however, in the case of a power
loss or having to pull the plug on a locked up system, it has a
noticeably higher chance of leaving you with an unbootable system than
if you were using
On 9/6/09 15:57, Dan Naumov wrote:
UFS2+SoftUpdates works fine on properly configured UFS2 - and very fast.
Yes, UFS2+SoftUpdates is very fast, however, in the case of a power
loss or having to pull the plug on a locked up system, it has a
noticeably higher chance of leaving you with an
or gjournal does
nothing for those who have existing systems with UFS2+softupdates, and
those who cannot use ZFS or gjournal in the near future for whatever
reason.
That being said, I do agree that being able to support ZFS and gjournal
in sysinstall or an alternative installer would be great
On Tue, Jun 9, 2009 at 11:50 AM, Vincent Hoffmanvi...@unsane.co.uk wrote:
[snip]
That said, there have been a few projects to update/replace/whatever
sysinstall, look at the desktopBSD installer (bsdinstaller) and
finstall. I'm not sure what the status of either of these 2 are though.
I was
On Tue, Jun 9, 2009 at 1:17 PM, Dan Naumovdan.nau...@gmail.com wrote:
Great! I am downloading
http://snapshots.pfsense.org/FreeBSD_8_0/FreeBSD-20090608-1522-8.0-CURRENT.iso.gz
as we speak and will give it a whirl within the next few days. Any
plans to do similar snapshot builds of -STABLE?
I
Interestingly in my experience its been the opposite, I've lost a few
ext3 filesystems though bad power, same for NTFS (NT4, less so with
200x) but as yet never for ufs2 (fsck has always fixed it.)
In worse cases it required manual attention :) UFS is used and improved
over 20 years, it's
noticeably higher chance of leaving you with an unbootable system than
if you were using Linux with ext3/ext4 or Windows with NTFS.
Can you back this up? I cannot recall having ever rendered a FreeBSD
system unbootable due to UFS/UFS2 problems after a power failure or
I can confirm the
On Tue, Jun 9, 2009 at 1:46 PM, Dan Naumovdan.nau...@gmail.com wrote:
What arch are these snapshots, are they amd64 or i386? Speaking of
-STABLE snapshots, since they are a more slowly moving target than
-CURRENT, 1 snapshot every week or so would definately be enough :)
These are i386
Great! I am downloading
http://snapshots.pfsense.org/FreeBSD_8_0/FreeBSD-20090608-1522-8.0-CURRENT.iso.gz
as we speak and will give it a whirl within the next few days. Any
plans to do similar snapshot builds of -STABLE?
- Dan Naumov
On Tue, Jun 9, 2009 at 7:58 PM, Scott
Dan Naumov wrote:
Hello list
Let me preface this by saying that I do not have coding
knowledge/experience, but I am willing to donate my time to help test
things if somebody is already working on this. Hopefully, this will
prevent most of the potential feel free to submit patches responses
What arch are these snapshots, are they amd64 or i386? Speaking of
-STABLE snapshots, since they are a more slowly moving target than
-CURRENT, 1 snapshot every week or so would definately be enough :)
- Dan Naumov
On Tue, Jun 9, 2009 at 8:31 PM, Scott Ullrichsullr...@gmail.com wrote:
On Tue,
Can you back this up? I cannot recall having ever rendered a FreeBSD
system unbootable due to UFS/UFS2 problems after a power failure or
crash. I once had a problem with snapshots that made background fsck
fail and crash the system, but it was fixable by booting single user and
running fsck
problem has since been fixed.
I've had several cases that needed manual fsck. After I turned off
background fsck, the problems stopped. These days background_fsck=NO
is a standard part of my rc.conf.
and mine.
actually snapshots doesn't work on large partitions - could simply crash.
that's
...@freebsd.org; freebsd-hackers@freebsd.org
Subject: Re: sysinstall, GJOURNAL and ZFS
filesystems/volumes of today, which can easily span 10tb+ in a
production environment, having to deal with fsck times is a complete
no-go.
just use large block sizes are really small amount of inodes. it's
unlikely
27 matches
Mail list logo
