Merge branch 'linus' into tracing/core

*.gz

*.lzma

*.patch

*.gcno

#

# Top-level generic files

!Finclude/net/mac80211.h ieee80211_ctstoself_get

!Finclude/net/mac80211.h ieee80211_ctstoself_duration

!Finclude/net/mac80211.h ieee80211_generic_frame_duration

!Finclude/net/mac80211.h ieee80211_get_hdrlen_from_skb

!Finclude/net/mac80211.h ieee80211_hdrlen

!Finclude/net/mac80211.h ieee80211_wake_queue

!Finclude/net/mac80211.h ieee80211_stop_queue

!Finclude/net/mac80211.h ieee80211_wake_queues

scatter-gather lists.

The controller will interleave the buffers on write and split them on

read.  This means that the Linux can DMA the data buffers to and from

read.  This means that Linux can DMA the data buffers to and from

host memory without changes to the page cache.

Also, the 16-bit CRC checksum mandated by both the SCSI and SATA specs

The IP checksum is weaker than the CRC in terms of detecting bit

errors.  However, the strength is really in the separation of the data

buffers and the integrity metadata.  These two distinct buffers much

buffers and the integrity metadata.  These two distinct buffers must

match up for an I/O to complete.

The separation of the data and integrity metadata buffers as well as

# /bin/echo 1-4 > cpus		-> set cpus list to cpus 1,2,3,4

# /bin/echo 1,2,3,4 > cpus	-> set cpus list to cpus 1,2,3,4

To add a CPU to a cpuset, write the new list of CPUs including the

CPU to be added. To add 6 to the above cpuset:

# /bin/echo 1-4,6 > cpus	-> set cpus list to cpus 1,2,3,4,6

Similarly to remove a CPU from a cpuset, write the new list of CPUs

without the CPU to be removed.

To remove all the CPUs:

# /bin/echo "" > cpus		-> clear cpus list

2.3 Setting flags

-----------------

Device-Mapper Logging

=====================

The device-mapper logging code is used by some of the device-mapper

RAID targets to track regions of the disk that are not consistent.

A region (or portion of the address space) of the disk may be

inconsistent because a RAID stripe is currently being operated on or

a machine died while the region was being altered.  In the case of

mirrors, a region would be considered dirty/inconsistent while you

are writing to it because the writes need to be replicated for all

the legs of the mirror and may not reach the legs at the same time.

Once all writes are complete, the region is considered clean again.

There is a generic logging interface that the device-mapper RAID

implementations use to perform logging operations (see

dm_dirty_log_type in include/linux/dm-dirty-log.h).  Various different

logging implementations are available and provide different

capabilities.  The list includes:

Type		Files

====		=====

disk		drivers/md/dm-log.c

core		drivers/md/dm-log.c

userspace	drivers/md/dm-log-userspace* include/linux/dm-log-userspace.h

The "disk" log type

-------------------

This log implementation commits the log state to disk.  This way, the

logging state survives reboots/crashes.

The "core" log type

-------------------

This log implementation keeps the log state in memory.  The log state

will not survive a reboot or crash, but there may be a small boost in

performance.  This method can also be used if no storage device is

available for storing log state.

The "userspace" log type

------------------------

This log type simply provides a way to export the log API to userspace,

so log implementations can be done there.  This is done by forwarding most

logging requests to userspace, where a daemon receives and processes the

request.

The structure used for communication between kernel and userspace are

located in include/linux/dm-log-userspace.h.  Due to the frequency,

diversity, and 2-way communication nature of the exchanges between

kernel and userspace, 'connector' is used as the interface for

communication.

There are currently two userspace log implementations that leverage this

framework - "clustered_disk" and "clustered_core".  These implementations

provide a cluster-coherent log for shared-storage.  Device-mapper mirroring

can be used in a shared-storage environment when the cluster log implementations

are employed.