On 01/04/2011 16:37, Marat N.Afanasyev wrote:
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
On 01/04/2011 16:47, 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.
I realise that people like having systems that come up quickly after a
crash, but is it worth reconsidering
Those are workarounds. A system should not reach to a point where it doesn't
come up because of a pending fsck. And even if it does console access must
be ensured. My point is that by disabling these you might bring it up but
you seriously risk data integrity.
Regards
On Sun, Apr 3, 2011 at 3:04
On Sun, 03 Apr 2011 13:04:54 +0100
Bruce Cran br...@cran.org.uk wrote:
On 01/04/2011 16:47, 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.
I realise that people like having
On 02/04/2011 04:35, Matthew Dillon wrote:
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
Date: Sun, 03 Apr 2011 18:20:27 +0100
From: Bruce Cran br...@cran.org.uk
Sender: owner-freebsd-sta...@freebsd.org
On 02/04/2011 04:35, Matthew Dillon wrote:
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
: Do you know if that's changed at all with NCQ on modern SATA drives?
: I've seen people commenting that using tags recovers most, if not all,
: of the performance lost by disabling the write cache.
:...
I've never tried that combination. Theoretically the 32 tags SATA
supports would
2011/4/2 Matthew Dillon dil...@apollo.backplane.com:
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
On Apr 1, 2011, at 23:35, Matthew Dillon wrote:
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
On Sat, Apr 02, 2011 at 12:55:15PM -0400, David Magda wrote:
On Apr 1, 2011, at 23:35, Matthew Dillon wrote:
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
:It should also be noted that some drives ignore or lie about these flush
commands: i.e., they say they flushed the buffers but did not in fact do so.
This is sometimes done on cheap SATA drives, but also on expensive SANS. If the
former's case it's often to help with benchmark numbers. In the
I am unaware of *ANY* mainstream hard drive or SSD made in the
last 10 years which ignores the disk flush command. In previous
decades HD vendors played games with caching all the time but there
are fewer HD vendors now and they all compete heavily with each
other... they don't play
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
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
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
George Kontostanos gkontos.m...@gmail.com 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
Marko Lerota wrote:
George Kontostanosgkontos.m...@gmail.com 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
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
On Fri, Apr 01, 2011 at 03:29:39PM +0200, Marko Lerota wrote:
George Kontostanos gkontos.m...@gmail.com 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
On Fri, Apr 01, 2011 at 03:29:39PM +0200, Marko Lerota wrote:
George Kontostanos gkontos.m...@gmail.com 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
On Fri, April 1, 2011 6:29 am, Marko Lerota wrote:
George Kontostanos gkontos.m...@gmail.com 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
On Fri, Apr 1, 2011 at 12:02 PM, Chris H chris#@1command.com 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.
On 1 April 2011 19:38, Adam Vande More amvandem...@gmail.com wrote:
On Fri, Apr 1, 2011 at 12:02 PM, Chris H chris#@1command.com 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
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
On Fri, April 1, 2011 10:38 am, Adam Vande More wrote:
On Fri, Apr 1, 2011 at 12:02 PM, Chris H chris#@1command.com 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.
On Fri, Apr 1, 2011 at 4:21 PM, Chris H chris#@1command.com 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
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,
27 matches
Mail list logo
