Skip to content

L
linux
Switch branch/tag
  1. 28 Jun, 2010 1 commit
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://neil.brown.name/md · 93416253
      Linus Torvalds authored 
      * 'for-linus' of git://neil.brown.name/md:
  md/raid5: don't include 'spare' drives when reshaping to fewer devices.
  md/raid5: add a missing 'continue' in a loop.
  md/raid5: Allow recovered part of partially recovered devices to be in-sync
  md/raid5: More careful check for "has array failed".
  md: Don't update ->recovery_offset when reshaping an array to fewer devices.
  md/raid5: avoid oops when number of devices is reduced then increased.
  md: enable raid4->raid0 takeover
  md: clear layout after ->raid0 takeover
  md: fix raid10 takeover: use new_layout for setup_conf
  md: fix handling of array level takeover that re-arranges devices.
  md: raid10: Fix null pointer dereference in fix_read_error()
  Restore partition detection of newly created md arrays.
      93416253
  3. 27 Jun, 2010 24 commits
  5. 26 Jun, 2010 8 commits
  7. 25 Jun, 2010 2 commits
  9. 24 Jun, 2010 5 commits
    • Miao Xie's avatar
      ext3: update ctime when changing the file's permission by setfacl · 30e2bab2
      Miao Xie authored 
      ext3 didn't update the ctime of the file when its permission was changed.

Steps to reproduce:
 # touch aaa
 # stat -c %Z aaa
 1275289822
 # setfacl -m  'u::x,g::x,o::x' aaa
 # stat -c %Z aaa
 1275289822				<- unchanged

But, according to the spec of the ctime, ext3 must update it.
Signed-off-by: default avatarMiao Xie <miaox@cn.fujitsu.com>
Signed-off-by: default avatarJan Kara <jack@suse.cz>
      30e2bab2
    • Jan Kara's avatar
      ext2: update ctime when changing the file's permission by setfacl · 523825bc
      Jan Kara authored 
      ext2 didn't update the ctime of the file when its permission was changed.

Steps to reproduce:
 # touch aaa
 # stat -c %Z aaa
 1275289822
 # setfacl -m  'u::x,g::x,o::x' aaa
 # stat -c %Z aaa
 1275289822                         <- unchanged

But, according to the spec of the ctime, ext2 must update it.

Port of ext3 patch by Miao Xie <miaox@cn.fujitsu.com>.
Signed-off-by: default avatarJan Kara <jack@suse.cz>
      523825bc
    • Timo Teräs's avatar
      xfrm: check bundle policy existance before dereferencing it · b1312c89
      Timo Teräs authored 
      Fix the bundle validation code to not assume having a valid policy.
When we have multiple transformations for a xfrm policy, the bundle
instance will be a chain of bundles with only the first one having
the policy reference. When policy_genid is bumped it will expire the
first bundle in the chain which is equivalent of expiring the whole
chain.
Reported-bisected-and-tested-by: default avatarJustin P. Mattock <justinmattock@gmail.com>
Signed-off-by: default avatarTimo Teräs <timo.teras@iki.fi>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b1312c89
    • NeilBrown's avatar
      md/raid5: don't include 'spare' drives when reshaping to fewer devices. · 3424bf6a
      NeilBrown authored 
      There are few situations where it would make any sense to add a spare
when reducing the number of devices in an array, but it is
conceivable:  A 6 drive RAID6 with two missing devices could be
reshaped to a 5 drive RAID6, and a spare could become available
just in time for the reshape, but not early enough to have been
recovered first.  'freezing' recovery can make this easy to
do without any races.

However doing such a thing is a bad idea.  md will not record the
partially-recovered state of the 'spare' and when the reshape
finished it will think that the spare is still spare.
Easiest way to avoid this confusion is to simply disallow it.
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      3424bf6a
    • NeilBrown's avatar
      md/raid5: add a missing 'continue' in a loop. · 2f115882
      NeilBrown authored 
      As the comment says, the tail of this loop only applies to devices
that are not fully in sync, so if In_sync was set, we should avoid
the rest of the loop.

This bug will hardly ever cause an actual problem.  The worst it
can do is allow an array to be assembled that is dirty and degraded,
which is not generally a good idea (without warning the sysadmin
first).

This will only happen if the array is RAID4 or a RAID5/6 in an
intermediate state during a reshape and so has one drive that is
all 'parity' - no data - while some other device has failed.

This is certainly possible, but not at all common.
Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      2f115882
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7