1. 30 4月, 2008 1 次提交
  2. 19 4月, 2008 1 次提交
  3. 27 1月, 2007 1 次提交
  4. 03 10月, 2006 1 次提交
    • N
      [PATCH] md: replace magic numbers in sb_dirty with well defined bit flags · 850b2b42
      NeilBrown 提交于
      Instead of magic numbers (0,1,2,3) in sb_dirty, we have
      some flags instead:
      MD_CHANGE_DEVS
         Some device state has changed requiring superblock update
         on all devices.
      MD_CHANGE_CLEAN
         The array has transitions from 'clean' to 'dirty' or back,
         requiring a superblock update on active devices, but possibly
         not on spares
      MD_CHANGE_PENDING
         A superblock update is underway.
      
      We wait for an update to complete by waiting for all flags to be clear.  A
      flag can be set at any time, even during an update, without risk that the
      change will be lost.
      
      Stop exporting md_update_sb - isn't needed.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      850b2b42
  5. 01 10月, 2006 1 次提交
    • D
      [PATCH] BLOCK: Make it possible to disable the block layer [try #6] · 9361401e
      David Howells 提交于
      Make it possible to disable the block layer.  Not all embedded devices require
      it, some can make do with just JFFS2, NFS, ramfs, etc - none of which require
      the block layer to be present.
      
      This patch does the following:
      
       (*) Introduces CONFIG_BLOCK to disable the block layer, buffering and blockdev
           support.
      
       (*) Adds dependencies on CONFIG_BLOCK to any configuration item that controls
           an item that uses the block layer.  This includes:
      
           (*) Block I/O tracing.
      
           (*) Disk partition code.
      
           (*) All filesystems that are block based, eg: Ext3, ReiserFS, ISOFS.
      
           (*) The SCSI layer.  As far as I can tell, even SCSI chardevs use the
           	 block layer to do scheduling.  Some drivers that use SCSI facilities -
           	 such as USB storage - end up disabled indirectly from this.
      
           (*) Various block-based device drivers, such as IDE and the old CDROM
           	 drivers.
      
           (*) MTD blockdev handling and FTL.
      
           (*) JFFS - which uses set_bdev_super(), something it could avoid doing by
           	 taking a leaf out of JFFS2's book.
      
       (*) Makes most of the contents of linux/blkdev.h, linux/buffer_head.h and
           linux/elevator.h contingent on CONFIG_BLOCK being set.  sector_div() is,
           however, still used in places, and so is still available.
      
       (*) Also made contingent are the contents of linux/mpage.h, linux/genhd.h and
           parts of linux/fs.h.
      
       (*) Makes a number of files in fs/ contingent on CONFIG_BLOCK.
      
       (*) Makes mm/bounce.c (bounce buffering) contingent on CONFIG_BLOCK.
      
       (*) set_page_dirty() doesn't call __set_page_dirty_buffers() if CONFIG_BLOCK
           is not enabled.
      
       (*) fs/no-block.c is created to hold out-of-line stubs and things that are
           required when CONFIG_BLOCK is not set:
      
           (*) Default blockdev file operations (to give error ENODEV on opening).
      
       (*) Makes some /proc changes:
      
           (*) /proc/devices does not list any blockdevs.
      
           (*) /proc/diskstats and /proc/partitions are contingent on CONFIG_BLOCK.
      
       (*) Makes some compat ioctl handling contingent on CONFIG_BLOCK.
      
       (*) If CONFIG_BLOCK is not defined, makes sys_quotactl() return -ENODEV if
           given command other than Q_SYNC or if a special device is specified.
      
       (*) In init/do_mounts.c, no reference is made to the blockdev routines if
           CONFIG_BLOCK is not defined.  This does not prohibit NFS roots or JFFS2.
      
       (*) The bdflush, ioprio_set and ioprio_get syscalls can now be absent (return
           error ENOSYS by way of cond_syscall if so).
      
       (*) The seclvl_bd_claim() and seclvl_bd_release() security calls do nothing if
           CONFIG_BLOCK is not set, since they can't then happen.
      Signed-Off-By: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      9361401e
  6. 27 6月, 2006 1 次提交
  7. 28 3月, 2006 2 次提交
    • N
      [PATCH] md: Checkpoint and allow restart of raid5 reshape · f6705578
      NeilBrown 提交于
      We allow the superblock to record an 'old' and a 'new' geometry, and a
      position where any conversion is up to.  The geometry allows for changing
      chunksize, layout and level as well as number of devices.
      
      When using verion-0.90 superblock, we convert the version to 0.91 while the
      conversion is happening so that an old kernel will refuse the assemble the
      array.  For version-1, we use a feature bit for the same effect.
      
      When starting an array we check for an incomplete reshape and restart the
      reshape process if needed.  If the reshape stopped at an awkward time (like
      when updating the first stripe) we refuse to assemble the array, and let
      user-space worry about it.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f6705578
    • N
      [PATCH] md: Final stages of raid5 expand code · 29269553
      NeilBrown 提交于
      This patch adds raid5_reshape and end_reshape which will start and finish the
      reshape processes.
      
      raid5_reshape is only enabled in CONFIG_MD_RAID5_RESHAPE is set, to discourage
      accidental use.
      
      Read the 'help' for the CONFIG_MD_RAID5_RESHAPE entry.
      
      and Make sure that you have backups, just in case.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      29269553
  8. 07 1月, 2006 1 次提交
    • N
      [PATCH] md: remove personality numbering from md · 2604b703
      NeilBrown 提交于
      md supports multiple different RAID level, each being implemented by a
      'personality' (which is often in a separate module).
      
      These personalities have fairly artificial 'numbers'.  The numbers
      are use to:
       1- provide an index into an array where the various personalities
          are recorded
       2- identify the module (via an alias) which implements are particular
          personality.
      
      Neither of these uses really justify the existence of personality numbers.
      The array can be replaced by a linked list which is searched (array lookup
      only happens very rarely).  Module identification can be done using an alias
      based on level rather than 'personality' number.
      
      The current 'raid5' modules support two level (4 and 5) but only one
      personality.  This slight awkwardness (which was handled in the mapping from
      level to personality) can be better handled by allowing raid5 to register 2
      personalities.
      
      With this change in place, the core md module does not need to have an
      exhaustive list of all possible personalities, so other personalities can be
      added independently.
      
      This patch also moves the check for chunksize being non-zero into the ->run
      routines for the personalities that need it, rather than having it in core-md.
       This has a side effect of allowing 'faulty' and 'linear' not to have a
      chunk-size set.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      2604b703
  9. 09 11月, 2005 2 次提交
    • N
      [PATCH] md: support BIO_RW_BARRIER for md/raid1 · a9701a30
      NeilBrown 提交于
      We can only accept BARRIER requests if all slaves handle
      barriers, and that can, of course, change with time....
      
      So we keep track of whether the whole array seems safe for barriers,
      and also whether each individual rdev handles barriers.
      
      We initially assumes barriers are OK.
      
      When writing the superblock we try a barrier, and if that fails, we flag
      things for no-barriers.  This will usually clear the flags fairly quickly.
      
      If writing the superblock finds that BIO_RW_BARRIER is -ENOTSUPP, we need to
      resubmit, so introduce function "md_super_wait" which waits for requests to
      finish, and retries ENOTSUPP requests without the barrier flag.
      
      When writing the real raid1, write requests which were BIO_RW_BARRIER but
      which aresn't supported need to be retried.  So raid1d is enhanced to do this,
      and when any bio write completes (i.e.  no retry needed) we remove it from the
      r1bio, so that devices needing retry are easy to find.
      
      We should hardly ever get -ENOTSUPP errors when writing data to the raid.
      It should only happen if:
        1/ the device used to support BARRIER, but now doesn't.  Few devices
           change like this, though raid1 can!
      or
        2/ the array has no persistent superblock, so there was no opportunity to
           pre-test for barriers when writing the superblock.
      Signed-off-by: NNeil Brown <neilb@cse.unsw.edu.au>
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a9701a30
    • N
      [PATCH] md: make md on-disk bitmaps not host-endian · bd926c63
      NeilBrown 提交于
      Current bitmaps use set_bit et.al and so are host-endian, which means
      not-portable.  Oops.
      
      Define a new version number (4) for which bitmaps are little-endian.
      Signed-off-by: NNeil Brown <neilb@suse.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      bd926c63
  10. 22 6月, 2005 3 次提交
  11. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4