Linux 3.6 fixes (part 1):

- sget() now takes one more arguments, which is the mount flag.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Linux 3.6 fixes (part 2):

- iops->lookup() now takes a unsigned int instead of struct nameidata.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Linux 3.6-rc1 Compatibility: Use .mkdir instead of .create in 3.3 compatibility check

Linux 3.6 modifies inode_operations->create's function prototype. This
causes an autotools Linux 3.3. compatibility check for a function
prototype change in create, mkdir and mknode to fail. The check that
Since mkdir and mknode are unchanged, we modify the check to examine it
instead.

Signed-off-by: Richard Yao <ryao@cs.stonybrook.edu>
Linux 3.6 fixes (part 3)

- .write_super is removed from super_operations.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Linux 3.6 fixes (part 4)

- .create in inode_operations takes a bool flag instead of struct
  nameidata.

Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Remove vmem_size() consumers

There are currently three vmem_size() consumers all of which are
part of the ARC implemention.  However, since the expected behavior
of the Linux and Solaris virtual memory subsystems are so different
the behavior in each of these instances needs to be reevaluated.

* arc_evict_needed() - This is actually dead code.  Arena support
was never added to the SPL and zio_arena is always NULL.  This
support isn't needed so we simply remove this dead code.

* arc_memory_throttle() - On Solaris where virtual memory constitutes
almost all of the address space we can reasonably expect there to be
a fairly large amount free.  However, on Linux by default we only
have about 100MB total and that's heavily used by the ARC.  So the
expectation on Linux is that this will usually be a small value.
Therefore we remove the vmem_size() check for i386 systems because
the expectation is that it will be less than the zfs_write_limit_max.

* arc_init() - Here vmem_size() is used to initially size the ARC.
Since the ARC is currently backed by the virtual address space it
makes sense to use this as a limit on the ARC for 32-bit systems.
This code can be removed when the ARC is backed by the page cache.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #831
Don't ashift-align vdev read requests.

Currently, the size of read and write requests on vdevs is aligned
according to the vdev's ashift, allocating a new ZIO buffer and padding
if need be.

This makes sense for write requests to prevent read/modify/write if the
write happens to be smaller than the device's internal block size.

For reads however, the rationale is less clear. It seems that the
original code aligns reads because, on Solaris, device drivers will
outright refuse unaligned requests.

We don't have that issue on Linux. Indeed, Linux block devices are able
to accept requests of any size, and take care of alignment issues
themselves.

As a result, there's no point in enforcing alignment for read requests
on Linux. This is a nice optimization opportunity for two reasons:
- We remove a memory allocation in a heavily-used code path;
- The request gets aligned in the lowest layer possible, which shrinks
  the path that the additional, useless padding data has to travel.
  For example, when using 4k-sector drives that lie about their sector
  size, using 512b read requests instead of 4k means that there will
  be less data traveling down the ATA/SCSI interface, even though the
  drive actually reads 4k from the platter.

The only exception is raidz, because raidz needs to read the whole
allocated block for parity.

This patch removes alignment enforcement for read requests, except on
raidz. Note that we also remove an assertion that checks that we're
aligning a top-level vdev I/O, because that's not the case anymore for
repair writes that results from failed reads.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Closes #1022