2011/4/2 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. Wel
On Thu, Mar 24, 2011 at 01:36:32PM -0700, Freddie Cash wrote:
> [Not sure which list is most appropriate since it's using HAST + ZFS
> on -RELEASE, -STABLE, and -CURRENT. Feel free to trim the CC: on
> replies.]
>
> I'm having a hell of a time making this work on real hardware, and am
> not rulin
TB --- 2011-04-02 08:01:56 - tinderbox 2.6 running on freebsd-legacy.sentex.ca
TB --- 2011-04-02 08:01:56 - starting RELENG_7 tinderbox run for sparc64/sparc64
TB --- 2011-04-02 08:01:56 - cleaning the object tree
TB --- 2011-04-02 08:02:09 - cvsupping the source tree
TB --- 2011-04-02 08:02:09 - /
Hi, all,
On my system using the "old" ATA driver, I can use a command like this
to get useful information about my disk drives:
nas-pmh# atacontrol cap ad4
Protocol SATA revision 2.x
device model ST32000542AS
seri
On Sat, Apr 02, 2011 at 11:34:32AM +0200, Patrick M. Hausen wrote:
> Hi, all,
>
> On my system using the "old" ATA driver, I can use a command like this
> to get useful information about my disk drives:
>
>
> nas-pmh# atacontrol cap ad4
Looked at rsync or tarsnap?
On Mon, 28 Mar 2011 09:20:07 +0200, Lev Serebryakov
wrote:
Hello, Freebsd-stable.
Now I'm backing up my HOME filesystem with dump(8). It works
perfectly for 80GiB FS with many features: snapshot for consistency,
levels, "nodump" flag (my users use it a lot!),
On Sat, Apr 02, 2011 at 12:04:09AM +0300, Mikolaj Golub wrote:
> 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).
The patch looks good. Pleas
Ahoy. This morning, I awoke to the following on one of my servers:
pid 59630 (httpd), uid 80, was killed: out of swap space
pid 59341 (find), uid 0, was killed: out of swap space
pid 23134 (irssi), uid 1001, was killed: out of swap space
pid 49332 (sshd), uid 1001, was killed: out of swap space
p
On Sat, Apr 02, 2011 at 10:17:27AM -0400, Boris Kochergin wrote:
> Ahoy. This morning, I awoke to the following on one of my servers:
>
> pid 59630 (httpd), uid 80, was killed: out of swap space
> pid 59341 (find), uid 0, was killed: out of swap space
> pid 23134 (irssi), uid 1001, was killed: out
On Sat, Apr 02, 2011 at 10:17:27AM -0400, Boris Kochergin wrote:
> Ahoy. This morning, I awoke to the following on one of my servers:
>
> pid 59630 (httpd), uid 80, was killed: out of swap space
> pid 59341 (find), uid 0, was killed: out of swap space
> pid 23134 (irssi), uid 1001, was killed: out
On 04/02/11 11:33, Kostik Belousov wrote:
On Sat, Apr 02, 2011 at 10:17:27AM -0400, Boris Kochergin wrote:
Ahoy. This morning, I awoke to the following on one of my servers:
pid 59630 (httpd), uid 80, was killed: out of swap space
pid 59341 (find), uid 0, was killed: out of swap space
pid 23134
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
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 Fre
: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 l
> 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
On Mon, 28 Mar 2011 03:20:07 -0400, Lev Serebryakov
wrote:
I'm thinking to transfer GOME filesystem to ZFS. But I can not find
appropriate tools for backing it up. Here is some requirements:
Have you considered a full-up backup solution, like bacula? It's a
client/server/server model b
16 matches
Mail list logo
