Searched +full:d +full:- +full:cache +full:- +full:block +full:- +full:size (Results 1 – 25 of 42) sorted by relevance
12
| /Documentation/devicetree/bindings/riscv/ |
| D | cpus.yaml | 1 # SPDX-License-Identifier: (GPL-2.0 OR MIT)
3 ---
5 $schema: http://devicetree.org/meta-schemas/core.yaml#
7 title: RISC-V bindings for 'cpus' DT nodes
10 - Paul Walmsley <paul.walmsley@sifive.com>
11 - Palmer Dabbelt <palmer@sifive.com>
14 This document uses some terminology common to the RISC-V community
18 mandated by the RISC-V ISA: a PC and some registers. This
28 - items:
29 - enum:
[all …]
|
| /Documentation/admin-guide/ |
| D | bcache.rst | 2 A block layer cache (bcache)
6 nice if you could use them as cache... Hence bcache.
10 - http://bcache.evilpiepirate.org
11 - http://evilpiepirate.org/git/linux-bcache.git
12 - http://evilpiepirate.org/git/bcache-tools.git
14 It's designed around the performance characteristics of SSDs - it only allocates
15 in erase block sized buckets, and it uses a hybrid btree/log to track cached
16 extents (which can be anywhere from a single sector to the bucket size). It's
17 designed to avoid random writes at all costs; it fills up an erase block
22 great lengths to protect your data - it reliably handles unclean shutdown. (It
[all …]
|
| D | md.rst | 5 ---------------------------------
16 md=<md device no.>,<raid level>,<chunk size factor>,<fault level>,dev0,dev1,...,devn
24 md=d<md device no.>,dev0,dev1,...,devn
49 -1 linear mode
55 ``chunk size factor``
58 (raid-0 and raid-1 only)
60 Set the chunk size as 4k << n.
78 --------------------------------------
87 that all auto-detected arrays are assembled as partitionable.
90 -------------------------------------------
[all …]
|
| /Documentation/filesystems/ |
| D | coda.txt | 3 Coda -- this document describes the client kernel-Venus interface.
10 To run Coda you need to get a user level cache manager for the client,
29 level filesystem code needed for the operation of the Coda file sys-
152 A key component in the Coda Distributed File System is the cache
160 client cache and makes remote procedure calls to Coda file servers and
179 leads to an almost natural environment for implementing a kernel-level
199 …l_o_s_e_, _c_r_e_a_t_e_, _m_k_d_i_r_, _r_m_d_i_r_, _c_h_m_o_d in a Unix
209 pre-processing, the VFS starts invoking exported routines in the FS
221 offered by the cache manager Venus. When the replies from Venus have
230 which does not block Venus since Venus must attend to other tasks even
[all …]
|
| D | affs.txt | 15 in file names are case-insensitive, as they ought to be.
20 DOS\4 The original filesystem with directory cache. The directory
21 cache speeds up directory accesses on floppies considerably,
25 DOS\5 The Fast File System with directory cache. Supported read only.
27 All of the above filesystems allow block sizes from 512 to 32K bytes.
28 Supported block sizes are: 512, 1024, 2048 and 4096 bytes. Larger blocks
60 root=block Sets the block number of the root block. This should never
63 bs=blksize Sets the blocksize to blksize. Valid block sizes are 512,
70 verbose The volume name, file system type and block size will
90 Amiga -> Linux:
[all …]
|
| D | ramfs-rootfs-initramfs.txt | 7 --------------
10 mechanisms (the page cache and dentry cache) as a dynamically resizable
11 RAM-based filesystem.
14 backing store (usually the block device the filesystem is mounted on) are kept
19 memory. A similar mechanism (the dentry cache) greatly speeds up access to
23 dentries and page cache as usual, but there's nowhere to write them to.
29 you're mounting the disk cache as a filesystem. Because of this, ramfs is not
34 ------------------
36 The older "ram disk" mechanism created a synthetic block device out of
37 an area of RAM and used it as backing store for a filesystem. This block
[all …]
|
| D | ceph.txt | 12 * N-way replication of data across storage nodes
22 on symmetric access by all clients to shared block devices, Ceph
28 re-replicated in a distributed fashion by the storage nodes themselves
33 in-memory cache above the file namespace that is extremely scalable,
35 and can tolerate arbitrary (well, non-Byzantine) node failures. The
40 loaded into its cache with a single I/O operation. The contents of
57 files and bytes. That is, a 'getfattr -d foo' on any directory in the
68 setfattr -n ceph.quota.max_bytes -v 100000000 /some/dir
69 getfattr -n ceph.quota.max_bytes /some/dir
81 # mount -t ceph monip[:port][,monip2[:port]...]:/[subdir] mnt
[all …]
|
| D | f2fs.txt | 2 WHAT IS Flash-Friendly File System (F2FS)?
5 NAND flash memory-based storage devices, such as SSD, eMMC, and SD cards, have
11 F2FS is a file system exploiting NAND flash memory-based storage devices, which
12 is based on Log-structured File System (LFS). The design has been focused on
16 Since a NAND flash memory-based storage device shows different characteristic
18 F2FS and its tools support various parameters not only for configuring on-disk
23 >> git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git
26 >> linux-f2fs-devel@lists.sourceforge.net
32 Log-structured File System (LFS)
33 --------------------------------
[all …]
|
| D | ext2.txt | 15 set using tune2fs(8). Kernel-determined defaults are indicated by (*).
23 dax Use direct access (no page cache). See
30 errors=remount-ro Remount the filesystem read-only on an error.
36 nouid32 Use 16-bit UIDs and GIDs.
38 oldalloc Enable the old block allocator. Orlov should
39 have better performance, we'd like to get some
41 orlov (*) Use the Orlov block allocator.
81 ------
84 a fixed size, of 1024, 2048 or 4096 bytes (8192 bytes on Alpha systems),
87 and also impose other limits on the size of files and the filesystem.
[all …]
|
| D | fsverity.rst | 1 .. SPDX-License-Identifier: GPL-2.0
6 fs-verity: read-only file-based authenticity protection
12 fs-verity (``fs/verity/``) is a support layer that filesystems can
14 of read-only files. Currently, it is supported by the ext4 and f2fs
15 filesystems. Like fscrypt, not too much filesystem-specific code is
16 needed to support fs-verity.
18 fs-verity is similar to `dm-verity
19 <https://www.kernel.org/doc/Documentation/device-mapper/verity.txt>`_
20 but works on files rather than block devices. On regular files on
21 filesystems supporting fs-verity, userspace can execute an ioctl that
[all …]
|
| /Documentation/filesystems/caching/ |
| D | cachefiles.txt | 2 CacheFiles: CACHE ON ALREADY MOUNTED FILESYSTEM
13 (*) Starting the cache.
17 (*) Cache culling.
19 (*) Cache structure.
34 CacheFiles is a caching backend that's meant to use as a cache a directory on
37 CacheFiles uses a userspace daemon to do some of the cache management - such as
41 The filesystem and data integrity of the cache are only as good as those of the
46 CacheFiles creates a misc character device - "/dev/cachefiles" - that is used
48 and while it is open, a cache is at least partially in existence. The daemon
49 opens this and sends commands down it to control the cache.
[all …]
|
| /Documentation/admin-guide/device-mapper/ |
| D | persistent-data.rst | 8 The more-sophisticated device-mapper targets require complex metadata
12 - Mikulas Patocka's multisnap implementation
13 - Heinz Mauelshagen's thin provisioning target
14 - Another btree-based caching target posted to dm-devel
15 - Another multi-snapshot target based on a design of Daniel Phillips
18 we'd like to reduce the number.
20 The persistent-data library is an attempt to provide a re-usable
21 framework for people who want to store metadata in device-mapper
22 targets. It's currently used by the thin-provisioning target and an
29 under drivers/md/persistent-data.
[all …]
|
| /Documentation/devicetree/ |
| D | booting-without-of.txt | 2 --------------------------------------------------
7 Freescale Semiconductor, FSL SOC and 32-bit additions
14 I - Introduction
21 II - The DT block format
24 3) Device tree "structure" block
25 4) Device tree "strings" block
27 III - Required content of the device tree
36 d) the /memory node(s)
40 IV - "dtc", the device tree compiler
42 V - Recommendations for a bootloader
[all …]
|
| /Documentation/admin-guide/blockdev/ |
| D | ramdisk.rst | 2 Using the RAM disk block device with Linux
9 3) Using "rdev -r"
14 -----------
16 The RAM disk driver is a way to use main system memory as a block device. It
18 in order to access the root filesystem (see Documentation/admin-guide/initrd.rst). It can
23 RAM from the buffer cache. The driver marks the buffers it is using as dirty
28 the configuration symbol BLK_DEV_RAM_COUNT in the Block drivers config menu
41 ---------------------------------
46 Size of the ramdisk.
48 This parameter tells the RAM disk driver to set up RAM disks of N k size. The
[all …]
|
| /Documentation/vm/ |
| D | frontswap.rst | 9 swapped pages are saved in RAM (or a RAM-like device) instead of a swap disk.
11 (Note, frontswap -- and :ref:`cleancache` (merged at 3.0) -- are the "frontends"
13 all other supporting code -- the "backends" -- is implemented as drivers.
21 a synchronous concurrency-safe page-oriented "pseudo-RAM device" conforming
23 in-kernel compressed memory, aka "zcache", or future RAM-like devices);
24 this pseudo-RAM device is not directly accessible or addressable by the
25 kernel and is of unknown and possibly time-varying size. The driver
49 cache" by calling frontswap_writethrough(). In this mode, the reduction
50 in swap device writes is lost (and also a non-trivial performance advantage)
87 and size (such as with compression) or secretly moved (as might be
[all …]
|
| /Documentation/translations/it_IT/process/ |
| D | coding-style.rst | 1 .. include:: ../disclaimer-ita.rst
3 :Original: :ref:`Documentation/process/coding-style.rst <codingstyle>`
24 ---------------
29 pi-greco a 3.
51 .. code-block:: c
73 .. code-block:: c
90 -----------------------------------
102 d'intestazione, alle funzioni con una lista di argomenti molto lunga. Tuttavia,
104 printk, questo perché inibireste la possibilità d'utilizzare grep per cercarle.
107 ---------------------------------------------
[all …]
|
| /Documentation/ide/ |
| D | ChangeLog.ide-cd.1994-2004 | 2 * 1.00 Oct 31, 1994 -- Initial version.
3 * 1.01 Nov 2, 1994 -- Fixed problem with starting request in
5 * 1.03 Nov 25, 1994 -- leaving unmask_intr[] as a user-setting (as for disks)
6 * (from mlord) -- minor changes to cdrom_setup()
7 * -- renamed ide_dev_s to ide_drive_t, enable irq on command
8 * 2.00 Nov 27, 1994 -- Generalize packet command interface;
10 * 2.01 Dec 3, 1994 -- Rework packet command interface to handle devices
12 * 2.02 Dec 11, 1994 -- Cache the TOC in the driver.
18 * 2.03 Jan 10, 1995 -- Rewrite block read routines to handle block sizes
21 * 2.04 Apr 21, 1995 -- Add work-around for Creative Labs CD220E drives.
[all …]
|
| /Documentation/ |
| D | DMA-API.txt | 8 of the API (and actual examples), see Documentation/DMA-API-HOWTO.txt.
11 Part II describes extensions for supporting non-consistent memory
13 non-consistent platforms (this is usually only legacy platforms) you
16 Part I - dma_API
17 ----------------
19 To get the dma_API, you must #include <linux/dma-mapping.h>. This
27 Part Ia - Using large DMA-coherent buffers
28 ------------------------------------------
33 dma_alloc_coherent(struct device *dev, size_t size,
42 This routine allocates a region of <size> bytes of consistent memory.
[all …]
|
| /Documentation/virt/kvm/ |
| D | mmu.txt | 10 - correctness: the guest should not be able to determine that it is running
13 a particular implementation such as tlb size)
14 - security: the guest must not be able to touch host memory not assigned
16 - performance: minimize the performance penalty imposed by the mmu
17 - scaling: need to scale to large memory and large vcpu guests
18 - hardware: support the full range of x86 virtualization hardware
19 - integration: Linux memory management code must be in control of guest memory
22 - dirty tracking: report writes to guest memory to enable live migration
23 and framebuffer-based displays
24 - footprint: keep the amount of pinned kernel memory low (most memory
[all …]
|
| /Documentation/driver-api/nvdimm/ |
| D | btt.rst | 2 BTT - Block Translation Table
10 accurately, cache line) granularity. However, we often want to expose such
11 storage as traditional block devices. The block drivers for persistent memory
14 using stored energy in capacitors to complete in-flight block writes, or perhaps
15 in firmware. We don't have this luxury with persistent memory - if a write is in
16 progress, and we experience a power failure, the block will contain a mix of old
19 The Block Translation Table (BTT) provides atomic sector update semantics for
21 being torn can continue to do so. The BTT manifests itself as a stacked block
23 the heart of it, is an indirection table that re-maps all the blocks on the
37 next arena). The following depicts the "On-disk" metadata layout::
[all …]
|
| D | nvdimm.rst | 2 LIBNVDIMM: Non-Volatile Devices
5 libnvdimm - kernel / libndctl - userspace helper library
7 linux-nvdimm@lists.01.org
20 BLK-REGIONs, PMEM-REGIONs, Atomic Sectors, and DAX
42 LIBNVDIMM/LIBNDCTL: Block Translation Table "btt"
52 A system-physical-address range where writes are persistent. A
53 block device composed of PMEM is capable of DAX. A PMEM address range
59 performance benefit of interleaving, but enables DIMM-bounded failure
63 DIMM Physical Address, is a DIMM-relative offset. With one DIMM in
64 the system there would be a 1:1 system-physical-address:DPA association.
[all …]
|
| /Documentation/process/ |
| D | coding-style.rst | 9 able to maintain, and I'd prefer it for most other things too. Please
12 First off, I'd suggest printing out a copy of the GNU coding standards,
19 --------------
27 a block of control starts and ends. Especially when you've been looking
31 Now, some people will claim that having 8-character indentations makes
33 80-character terminal screen. The answer to that is that if you need
37 In short, 8-char indents make things easier to read, and have the added
43 instead of ``double-indenting`` the ``case`` labels. E.g.:
45 .. code-block:: c
67 .. code-block:: c
[all …]
|
| /Documentation/block/ |
| D | biodoc.rst | 2 Notes on the Generic Block Layer Rewrite in Linux 2.5
13 - Jens Axboe <jens.axboe@oracle.com>
14 - Suparna Bhattacharya <suparna@in.ibm.com>
19 - Nick Piggin <npiggin@kernel.dk>
24 These are some notes describing some aspects of the 2.5 block layer in the
34 - Jens Axboe <jens.axboe@oracle.com>
36 Many aspects of the generic block layer redesign were driven by and evolved
43 - Christoph Hellwig <hch@infradead.org>
44 - Arjan van de Ven <arjanv@redhat.com>
45 - Randy Dunlap <rdunlap@xenotime.net>
[all …]
|
| /Documentation/trace/ |
| D | ftrace.rst | 2 ftrace - Function Tracer
13 - Written for: 2.6.28-rc2
14 - Updated for: 3.10
15 - Updated for: 4.13 - Copyright 2017 VMware Inc. Steven Rostedt
16 - Converted to rst format - Changbin Du <changbin.du@intel.com>
19 ------------
24 performance issues that take place outside of user-space.
41 ----------------------
43 See :doc:`ftrace-design` for details for arch porters and such.
47 ---------------
[all …]
|
| /Documentation/scsi/ |
| D | arcmsr_spec.txt | 6 ** 1. Message 0 --> InitThread message and return code
7 ** 2. Doorbell is used for RS-232 emulation
8 ** inDoorBell : bit0 -- data in ready
10 ** bit1 -- data out has been read
12 ** outDooeBell: bit0 -- data out ready
14 ** bit1 -- data in has been read
23 ** 4. RS-232 emulation
25 ** 1st uint32_t : Data length (1--124)
26 ** Byte 4--127 : Max 124 bytes of data
30 ** #bit27--bit31 => flag for post ccb
[all …]
|
12