The 2006 Linux Filesystems Workshop (Part III) [LWN.net]

The 2006 Linux Filesystems Workshop (Part III)

Posted Jul 23, 2006 19:12 UTC (Sun) by rapsys (guest, #39313)
In reply to: The 2006 Linux Filesystems Workshop (Part III) by dlang
Parent article: The 2006 Linux Filesystems Workshop (Part III)

I was wondering if you may add in your schema the following features :
- each 5chunk beeing marked as md5 control sum (some of raid5 over chunk)
- blacklist chunk that did 1-2 errors (as they have a weak magnetic
surface for example)

I think that two idea are interesting as I readed some article about
independant read/write head in hard disk for future to improve the
concurrent reading/write.
I read that there is 3-4year about Video Hard Disc Recorder for TV (but
hdtv and drm may have killed such improvement ?)

The point is that if we are able to have 3-5 head on a hard disk, why not
mark one of that head surface to be reserved to backup control sum ?
(this would not kill performance if head are independant as disk bandwith
is far bigger than the mechanic part)

(Log in to post comments)

The 2006 Linux Filesystems Workshop (Part III)

Posted Jul 23, 2006 19:40 UTC (Sun) by rapsys (guest, #39313) [Link]

Hum, I forget something.

The interest of the previous idea is if your data has been physicaly
corrupted (write overpowered, etc) in the other chunk, of the (group
of )block checksum will be wrong.
If the chunk of control sum is avaible and valid (see below), the kernel
issue a EAGAIN/ERESTORING to the application and regenerate the data from
the control sums' chunk.
It will allow to not loose a movie/music file because a stupid block in
the middle have been corrupted :'(

The more interesting things is that the hard disk will remap the
problematic magnic part to somewhere else because you re-write on the same
place and it's marked as trashed by hd.
(it's an assumption that need to be true every time and hd manufacturer
NEED to respect, after few write/read cycle test scheduled by firmware on
that place maybe)

The only problem I see if an overpowered writes cross the chunk
separation.
The control sum will be corrupted and will lead kernel in trouble in case
of birthday paradox.

So we will need to have (group of )block checksum for the control sums'
chunk too.
(Will it fit in space with equation : x(data)+1(control sums) ?)

I made two assumption :
- read/write to that chunk is not too costly (independant head, etc)
- control sum are not cpu killer (maybe have a special feature in hd to do
that job)
- control sums of chunk are not cpu killer too (but we only increase the
consumed cpu time for each write on disk)