:The topic of BIO_FLUSH is something I got to thinking about last night
:at work; the only condition where a disk with write caching enabled
:*would not* fully write the data to the platter would in fact be power
:loss. All other conditions (specifically soft reset and panic) should
:not require
On Mon, Sep 29, 2008 at 10:44:11AM -0700, Matthew Dillon wrote:
> A couple of things to note here. Well, many things actually.
Matt, I just wanted to take a moment to thank you for your verbose
and thorough outline of the issues as you see them. You're the
first developer (albeit Dragonfly :
Jeremy Chadwick wrote:
You're the first person I've encountered who has had to disable the ZIL
to get stability in ZFS; ouch, that must hurt.
Its not so bad: this machine is doing backups with rsync, sometimes
running 50 simultaneously. This workload doesn't contain any need for
synchronous
On Tue, Sep 30, 2008 at 11:40:46AM +1000, Andrew Snow wrote:
>
> Matthew Dillon wrote:
>> It can take 6 hours to fsck a full 1TB HD. It can
>> take over a day to fsck larger setups. Putting in a few sleeps here
>> and there just makes the run time even longer and perpetuates the pain.
>
>
Dan Nelson wrote:
That'd be handy, but at least on my system the data prefetcher isn't
really called often enough to make a difference either way (assuming
the counts are accurate). Metadata prefetch is a big win, however.
arcstats.prefetch_data_hits: 4538242 (13%)
arcstats.prefetch_data_misse
In the last episode (Sep 30), Andrew Snow said:
> Zaphod Beeblebrox wrote:
> > Also, there exists data within the ARC (I'm always tempted to say
> > the ARC Cache, but that is redundant) that is also then in paging
> > memory.
>
> OK, but one advantage of ZFS memory consumption is under heavy writ
:Completely agree. ZFS is the way of the future for FreeBSD. In my
:latest testing, the memory problems are now under control, there is just
:stability problems with random lockups after days of heavy load unless I
:turn off ZIL. So its nearly there.
:
:If only ZFS also supported a network dist
Zaphod Beeblebrox wrote:
Also, there
exists data within the ARC (I'm always tempted to say the ARC Cache, but
that is redundant) that is also then in paging memory.
OK, but one advantage of ZFS memory consumption is under heavy write
loads, where much of the memory is used to store and reorde
Matthew Dillon wrote:
It can take 6 hours to fsck a full 1TB HD. It can
take over a day to fsck larger setups. Putting in a few sleeps here
and there just makes the run time even longer and perpetuates the pain.
We have a box with millions of files spread over 2TB, on a 16 disk RAID.
A couple of things to note here. Well, many things actually.
* Turning off write caching, assuming the drive even looks at the bit,
will destroy write performance for any driver which does not support
command queueing. So, for example, scsi typically has command
queuein
On Mon, Sep 29, 2008 at 03:31:35PM +0200, Miroslav Lachman wrote:
> >Having been bitten by problems in this area more than once, I now always
> >disable background fsck. Having it disabled by default has my vote too.
> Is there any possibility to selectively disable / enable background fsck
> on
On Mon, Sep 29, 2008 at 11:09 AM, Zaphod Beeblebrox <[EMAIL PROTECTED]>wrote:
>
> I certainly can't agree with this. I don't think you're measuring the
> performance of the machine --- only measuring the performance of the
> filesystem. When ZFS is active, memory is committed in the kernel to ZF
On Mon, Sep 29, 2008 at 3:16 AM, Andrew Snow <[EMAIL PROTECTED]> wrote:
> However, as a core general purpose filesystem, it seems to have flaws, not
>> the least of which is a re-separation of file cache and memory cache.
>>
>
> For me, this doesn't matter because ZFS is so much faster than UFS
>
On Sat, Sep 27, 2008 at 05:36:17PM +1000, Peter Jeremy wrote:
> On 2008-Sep-26 23:44:17 -0700, Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
> >On Fri, Sep 26, 2008 at 10:35:57PM -0700, Derek Kuli??ski wrote:
> >> As far as I know (at least ideally, when write caching is disabled)
> ...
> >FreeBSD ata
[EMAIL PROTECTED] wrote:
IMHO, a dirty filesystem should not be mounted until it's been fully
analysed/scanned by fsck. So again, people are putting faith into
UFS2+SU despite actual evidence proving that it doesn't handle all
scenarios.
Yes, I think the background fsck should be disabled by
However, as a core general purpose filesystem, it seems to have flaws, not
the least of which is a re-separation of file cache and memory cache.
For me, this doesn't matter because ZFS is so much faster than UFS
overall. Even if you don't use any of its features, the latest version
does sequent
On Mon, Sep 29, 2008 at 12:00 AM, Jeremy Chadwick <[EMAIL PROTECTED]>wrote:
> On Sun, Sep 28, 2008 at 11:30:01PM -0400, Zaphod Beeblebrox wrote:
>
> > However, as a core general purpose filesystem, it seems to have flaws,
> not
> > the least of which is a re-separation of file cache and memory c
On Sun, Sep 28, 2008 at 11:30:01PM -0400, Zaphod Beeblebrox wrote:
> On Sat, Sep 27, 2008 at 3:37 AM, Derek Kuli?ski <[EMAIL PROTECTED]> wrote:
>
> >
> > > ZFS is the first filesystem, to my knowledge, which provides 1) a
> > > reliable filesystem, 2) detection of filesystem problems in real-time
On Sat, Sep 27, 2008 at 3:37 AM, Derek Kuliński <[EMAIL PROTECTED]> wrote:
>
> > ZFS is the first filesystem, to my knowledge, which provides 1) a
> > reliable filesystem, 2) detection of filesystem problems in real-time or
> > during scrubbing, 3) repair of problems in real-time (assuming raidz1
Jeremy Chadwick wrote:
> I believe we're in overall agreement with regards to background_fsck
> (should be disabled by default).
In fact background fsck has been introduced for a good reason:
waiting for a full fsck on modern big disks is far too long.
Similarly write cache is enabled on ata disk
[EMAIL PROTECTED] wrote:
> [...]
> > > IMHO, a dirty filesystem should not be mounted until it's been fully
> > > analysed/scanned by fsck. So again, people are putting faith into
> > > UFS2+SU despite actual evidence proving that it doesn't handle all
> > > scenarios.
> >
> > Yes, I think
On Sat, Sep 27, 2008 at 12:37:50AM -0700, Derek Kuli??ski wrote:
> Friday, September 26, 2008, 11:44:17 PM, you wrote:
>
> >> As far as I know (at least ideally, when write caching is disabled)
>
> > Re: write caching: wheelies and burn-outs in empty parking lots
> > detected.
>
> > Let's be rea
> > IMHO, a dirty filesystem should not be mounted until it's been fully
> > analysed/scanned by fsck. So again, people are putting faith into
> > UFS2+SU despite actual evidence proving that it doesn't handle all
> > scenarios.
>
> Yes, I think the background fsck should be disabled by default,
On Fri, Sep 26, 2008 at 11:44:17PM -0700, Jeremy Chadwick wrote:
> On Fri, Sep 26, 2008 at 10:35:57PM -0700, Derek Kuli??ski wrote:
> > Hello Jeremy,
> >
> > Friday, September 26, 2008, 10:14:13 PM, you wrote:
> >
> > >> Actually what's the advantage of having fsck run in background if it
> > >>
Hello Jeremy,
Friday, September 26, 2008, 11:44:17 PM, you wrote:
>> As far as I know (at least ideally, when write caching is disabled)
> Re: write caching: wheelies and burn-outs in empty parking lots
> detected.
> Let's be realistic. We're talking about ATA and SATA hard disks, hooked
> up
On 2008-Sep-26 23:44:17 -0700, Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
>On Fri, Sep 26, 2008 at 10:35:57PM -0700, Derek Kuli??ski wrote:
>> As far as I know (at least ideally, when write caching is disabled)
...
>FreeBSD atacontrol does not let you toggle such features (although "cap"
>will show
On Fri, Sep 26, 2008 at 10:35:57PM -0700, Derek Kuli??ski wrote:
> Hello Jeremy,
>
> Friday, September 26, 2008, 10:14:13 PM, you wrote:
>
> >> Actually what's the advantage of having fsck run in background if it
> >> isn't capable of fixing things?
> >> Isn't it more dangerous to be it like that
Hello Jeremy,
Friday, September 26, 2008, 10:14:13 PM, you wrote:
>> Actually what's the advantage of having fsck run in background if it
>> isn't capable of fixing things?
>> Isn't it more dangerous to be it like that? i.e. administrator might
>> not notice the problem; also filesystem could bre
On Fri, Sep 26, 2008 at 09:33:41PM -0700, Derek Kuli??ski wrote:
> Hello Jeremy,
>
> Sunday, September 21, 2008, 3:07:20 PM, you wrote:
>
> > Consider using background_fsck="no" in /etc/rc.conf if you prefer the
> > old behaviour. Otherwise, boot single-user then do the fsck.
>
> Actually what'
Hello Jeremy,
Sunday, September 21, 2008, 3:07:20 PM, you wrote:
> Consider using background_fsck="no" in /etc/rc.conf if you prefer the
> old behaviour. Otherwise, boot single-user then do the fsck.
Actually what's the advantage of having fsck run in background if it
isn't capable of fixing th
On Sep 21, Jeremy Chadwick wrote:
> The tool is behaving how it should. Try using the -a flag.
Ok, I feel dumb now :)
Thanks,
-Clint
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
___
On Sun, Sep 21, 2008 at 05:40:40PM -0700, Clint Olsen wrote:
> On Sep 21, Jeremy Chadwick wrote:
> > With regards to this specific item: can you provide the full smartctl
> > command you're using (including device), and all of the output? I have
> > an idea of what the problem is, but I'd need to
On Sep 21, Jeremy Chadwick wrote:
> With regards to this specific item: can you provide the full smartctl
> command you're using (including device), and all of the output? I have
> an idea of what the problem is, but I'd need to see the output first.
# smartctl /dev/ad6
smartctl version 5.38 [i38
On Sun, Sep 21, 2008 at 04:59:50PM -0700, Clint Olsen wrote:
> > Also, are there any kernel messages about ATA/SCSI disk errors or other
> > anomalies?
>
> None. In fact smartctl will not do anything now. It just prints out the
> quick banner message and exits immediately with no error.
With re
On Sep 21, Jeremy Chadwick wrote:
> You could also consider using clri(8) to clear the inode (190). Do this
> in single-user while the filesystem is not mounted. After using clri,
> run fsck a couple times.
Booting single-user and running fsck again seems to have corrected these
errors. For som
On Sep 21, Jeremy Chadwick wrote:
> Re-adding mailing list to the CC list.
>
> No, I don't think that is the case, assuming the filesystems are UFS2
> and are using softupdates. When booting multi-user, fsck is run in the
> background, meaning the system is fully up + usable even before the fsck
On Sun, Sep 21, 2008 at 02:59:30PM -0700, Clint Olsen wrote:
> I ran in multi-user mode because the system booted. I figured that it
> would have halted the boot if it was serious enough to warrant single-user
> mode fsck. That has happened before.
>
> Thanks,
>
> -Clint
>
> On Sep 21, Jeremy C
On Sun, Sep 21, 2008 at 02:34:26PM -0700, Clint Olsen wrote:
> Sep 21 08:57:54 belle fsck: /dev/ad4s1d: 1 DUP I=190
> Sep 21 08:57:54 belle fsck: /dev/ad4s1d: UNEXPECTED SOFT UPDATE
> INCONSISTENCY; RUN fsck MANUALLY.
>
> Ok, so I ran fsck manually (even with -y), but yet it refus
Sep 21 08:57:54 belle fsck: /dev/ad4s1d: 1 DUP I=190
Sep 21 08:57:54 belle fsck: /dev/ad4s1d: UNEXPECTED SOFT UPDATE INCONSISTENCY;
RUN fsck MANUALLY.
Ok, so I ran fsck manually (even with -y), but yet it refuses to clear/fix
whatever to the questions posed as fsck runs. What does this all mean
39 matches
Mail list logo
