1 |
On Thursday, September 01, 2016 04:21:18 PM J. Roeleveld wrote: |
2 |
> On Thursday, September 01, 2016 08:41:39 AM Michael Mol wrote: |
3 |
> > On Wednesday, August 31, 2016 11:45:15 PM Alan McKinnon wrote: |
4 |
> > > On 31/08/2016 17:25, Grant wrote: |
5 |
> > > >> Which NTFS system are you using? |
6 |
> > > >> |
7 |
> > > >> ntfs kernel module? It's quite dodgy and unsafe with writes |
8 |
> > > >> ntfs-ng on fuse? I find that one quite solid |
9 |
> > > > |
10 |
> > > > I'm using ntfs-ng as opposed to the kernel option(s). |
11 |
> > > |
12 |
> > > I'm offering 10 to 1 odds that your problems came from ... one that you |
13 |
> > > yanked too soon |
14 |
> > |
15 |
> > (pardon the in-line snip, while I get on my soap box) |
16 |
> > |
17 |
> > The likelihood of this happening can be greatly reduced by setting |
18 |
> > vm.dirty_bytes to something like 2097125 and vm.dirty_background_bytes to |
19 |
> > something like 1048576. This prevents the kernel from queuing up as much |
20 |
> > data for sending to disk. The application doing the copy or write will |
21 |
> > normally report "complete" long before writes to slow media are |
22 |
> > actually...complete. Setting vm.dirty_bytes to something low prevents the |
23 |
> > kernel's backlog of data from getting so long. |
24 |
> > |
25 |
> > vm.dirty_bytes has another, closely-related setting, vm.dirty_bytes_ratio. |
26 |
> > vm.dirty_bytes_ratio is a percentage of RAM that is used for dirty bytes. |
27 |
> > If vm.dirty_bytes_ratio is set, vm.dirty_bytes will read 0. If |
28 |
> > vm.dirty_bytes is set, vm.dirty_bytes_ratio will read 0. |
29 |
> > |
30 |
> > The default is for vm.dirty_bytes_ratio to be 20, which means up to 20% of |
31 |
> > your memory can find itself used as a write buffer for data on its way to |
32 |
> > a |
33 |
> > filesystem. On a system with only 2GiB of RAM, that's 409MiB of data that |
34 |
> > the kernel may still be waiting to push through the filesystem layer! If |
35 |
> > you're writing to, say, a class 10 SDHC card, the data may not be at rest |
36 |
> > for another 40s after the application reports the copy operation is |
37 |
> > complete! |
38 |
> > |
39 |
> > If you've got a system with 8GiB of memory, multiply all that by four. |
40 |
> > |
41 |
> > The defaults for vm.dirty_bytes and vm.dirty_background_bytes are, IMO, |
42 |
> > badly broken and an insidious source of problems for both regular Linux |
43 |
> > users and system administrators. |
44 |
> |
45 |
> I would prefer to be able to have different settings per disk. |
46 |
> Swappable drives like USB, I would put small numbers. |
47 |
> But for built-in drives, I'd prefer to keep default values or tuned to the |
48 |
> actual drive. |
49 |
|
50 |
The problem is that's not really possible. vm.dirty_bytes and |
51 |
vm.dirty_background_bytes deal with the page cache, which sits at the VFS |
52 |
layer, not the block device layer. It could certainly make sense to apply it |
53 |
on a per-mount basis, though. |
54 |
|
55 |
-- |
56 |
:wq |