[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[dm-devel] Patchset 2.4.20-dm-9


Changes since 2.4.20-dm-8

Revision 48:
  In snapshot_ctr(), if the call to register_snapshot() fails, we need to unlock
  the origin's filesystem (if the VFS-lock patch has been applied).
  [Kevin Corry]

Revision 49:
  In persistent_prepare(), when incrementing the next_free field and checking
  for the location for the next metadata area, it doesn't seem to account for
  the header chunk at the beginning of the cow device.
  For example: 
     chunk_size = 32 (16k)
     exceptions_per_area = 1024
     stride = 1025
     The header is chunk 0, the first metadata area is chunk 1, and the first
     data area is chunks 2 through 1025. When next_free equals 1024 (the second-
     to-last data chunk in the first area), it will be incremented to 1025, then
     mod'd with stride to get 0, and then incremented again to 1026. This
     effectively skips the last data chunk in the first data area and sets
     next_free to the chunk for the second metadata area. I'm guessing this
     will eventually look like data corruption if the snapshot tries to read
     data from that chunk, since it will eventually be overwritten by metadata.
  This patch corrects this by checking for a mod value of 1, instead of 0.
  Another possible solution would be to change the prefix-increment to a
  postfix-increment.  [Kevin Corry]

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]