1 |
Daniels advice is actually the best that you can get. It will give |
2 |
you the smallest chance of corruption due out of order journal commits |
3 |
that caching can cause. |
4 |
|
5 |
js |
6 |
|
7 |
|
8 |
On 10/31/06, Daniel Iliev <danny@××××××××.com> wrote: |
9 |
> Alan McKinnon wrote: |
10 |
> > On Tuesday 31 October 2006 11:04, Uwe Thiem wrote: |
11 |
> > |
12 |
> >> On 31 October 2006 09:17, Alan McKinnon wrote: |
13 |
> >> |
14 |
> >>> I find it useful to keep in mind that XFS is a file-system (i.e. a |
15 |
> >>> system for files), and not necessarily a severly disk-bound |
16 |
> >>> filesystem |
17 |
> >>> |
18 |
> >> Would you mind to elaborate on this? I simply do not get your point. |
19 |
> >> |
20 |
> > |
21 |
> > Historically SGI was very strong in graphics, and those applicatiosn |
22 |
> > tended to generate massive amounts of temporary files that had a short |
23 |
> > life and only the final version needs to be written to persistent |
24 |
> > storage, very well suited to aggressive caching and other similar |
25 |
> > speedups. |
26 |
> > |
27 |
> > SGI's engineers could get away with this because they could guarantee |
28 |
> > that power loss to the machine wouldn't happen, so the potential data |
29 |
> > loss on a power outage didn't happen either. This sounds a bit weird to |
30 |
> > those of us raised on Intel where we pay close attention to getting |
31 |
> > everything on disk ASAP with as little performance loss as possible, |
32 |
> > but it's a perfectly reasonable system for an engineer to implement on |
33 |
> > the kind of hardware SGI were building. |
34 |
> > |
35 |
> > That's why I say XFS is designed to not be tightly bound to the physical |
36 |
> > disk if the admin chooses to set it up that way, and the file system |
37 |
> > becomes more of a collection of directories and files that might never |
38 |
> > even be stored on a disk at all |
39 |
> > |
40 |
> > alan |
41 |
> > |
42 |
> |
43 |
> "..we pay close attention to getting everything on disk ASAP with as little performance loss as possible.." |
44 |
> |
45 |
> Then I would propose you to use "hdparm -W0 /dev/(what-ever)" to disable the write caching (no matter which FS you use). Nothing can give 100% guarantee against power failure. |
46 |
> |
47 |
> |
48 |
> -- |
49 |
> Best regards, |
50 |
> Daniel |
51 |
> |
52 |
> |
53 |
> -- |
54 |
> gentoo-user@g.o mailing list |
55 |
> |
56 |
> |
57 |
-- |
58 |
gentoo-user@g.o mailing list |