1. 17 10月, 2007 2 次提交
  2. 09 5月, 2007 2 次提交
    • J
      ext3: copy i_flags to inode flags on write · 4f99ed67
      Jan Kara 提交于
      Propagate flags such as S_APPEND, S_IMMUTABLE, etc.  from i_flags into
      ext2-specific i_flags.  Hence, when someone sets these flags via a different
      interface than ioctl, they are stored correctly.
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4f99ed67
    • M
      ext2/3/4: fix file date underflow on ext2 3 filesystems on 64 bit systems · 4d7bf11d
      Markus Rechberger 提交于
      Taken from http://bugzilla.kernel.org/show_bug.cgi?id=5079
      
      signed long ranges from -2.147.483.648 to 2.147.483.647 on x86 32bit
      
      10000011110110100100111110111101 .. -2,082,844,739
      10000011110110100100111110111101 ..  2,212,122,557 <- this currently gets
      stored on the disk but when converting it to a 64bit signed long value it loses
      its sign and becomes positive.
      
      Cc: Andreas Dilger <adilger@dilger.ca>
      Cc: <linux-ext4@vger.kernel.org>
      
      Andreas says:
      
      This patch is now treating timestamps with the high bit set as negative
      times (before Jan 1, 1970).  This means we lose 1/2 of the possible range
      of timestamps (lopping off 68 years before unix timestamp overflow -
      now only 30 years away :-) to handle the extremely rare case of setting
      timestamps into the distant past.
      
      If we are only interested in fixing the underflow case, we could just
      limit the values to 0 instead of storing negative values.  At worst this
      will skew the timestamp by a few hours for timezones in the far east
      (files would still show Jan 1, 1970 in "ls -l" output).
      
      That said, it seems 32-bit systems (mine at least) allow files to be set
      into the past (01/01/1907 works fine) so it seems this patch is bringing
      the x86_64 behaviour into sync with other kernels.
      
      On the plus side, we have a patch that is ready to add nanosecond timestamps
      to ext3 and as an added bonus adds 2 high bits to the on-disk timestamp so
      this extends the maximum date to 2242.
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4d7bf11d
  3. 27 9月, 2006 1 次提交
  4. 29 6月, 2006 1 次提交
  5. 27 3月, 2006 1 次提交
  6. 02 2月, 2006 1 次提交
  7. 31 10月, 2005 1 次提交
  8. 10 9月, 2005 1 次提交
  9. 24 6月, 2005 1 次提交
  10. 17 4月, 2005 2 次提交
    • B
      [PATCH] ext2 corruption - regression between 2.6.9 and 2.6.10 · e072c6f2
      Bernard Blackham 提交于
      Whilst trying to stress test a Promise SX8 card, we stumbled across
      some nasty filesystem corruption in ext2. Our tests involved
      creating an ext2 partition, mounting, running several concurrent
      fsx's over it, umounting, and fsck'ing, all scripted[1]. The fsck
      would always return with errors.
      
      This regression was traced back to a change between 2.6.9 and
      2.6.10, which moves the functionality of ext2_put_inode into
      ext2_clear_inode.  The attached patch reverses this change, and
      eliminated the source of corruption.
      
      Mingming Cao <cmm@us.ibm.com> said:
      
      I think his patch for ext2 is correct.  The corruption on ext3 is not the same
      issue he saw on ext2.  I believe that's the race between discard reservation
      and reservation in-use that we already fixed it in 2.6.12- rc1.
      
      For the problem related to ext2, at the time when we design reservation for
      ext3, we decide we only need to discard the reservation at the last file
      close, so we have ext3_discard_reservation on iput_final- >ext3_clear_inode.
      
      The ext2 handle discard preallocation differently at that time, it discard the
      preallocation at each iput(), not in input_final(), so we think it's
      unnecessary to thrash it so frequently, and the right thing to do, as we did
      for ext3 reservation, discard preallocation on last iput().  So we moved the
      ext2_discard_preallocation from ext2_put_inode(0 to ext2_clear_inode.
      
      Since ext2 preallocation is doing pre-allocation on disk, so it is possible
      that at the unmount time, someone is still hold the reference of the inode, so
      the preallocation for a file is not discard yet, so we still mark those blocks
      allocated on disk, while they are not actually in the inode's block map, so
      fsck will catch/fix that error later.
      
      This is not a issue for ext3, as ext3 reservation(pre-allocation) is done in
      memory.
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e072c6f2
    • 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