It was wrong back then and it's wrong now
Posted Nov 8, 2008 3:15 UTC (Sat) by
Ze (guest, #54182)
In reply to:
It was wrong back then and it's wrong now by khim
Parent article:
Linux and object storage devices
Yes - and I've certainly had problems with the first and I'm sure I'll have problems with the second. The only sane way to resolve this problem is to offer as low access as possible - but not lower. I don't think checksum calculation for blocks on HDD belongs to OS kernel (it can be calculated in HDD more or less for free, but general-purpose CPU will spend significant power doing it), but bad blocks handling certainly should belong to kernel - it have more resources to cope.
Yes and what about the bandwidth requirements of sending the checksum over? or if someone wishes to use that space for an error correcting code or a more secure hash?
Ultimately the time spent transferring files from the disk should be a small percentage compared to the time spent waiting for them. However there are always going to be trade offs with flexibility , speed and other things.
What is the goal: great storage subsystem or great system? If the latter then all these things must be done at the system level (and may be offered via NFS/CIFS).
OBS is quite bad idea but Linux will need some support for it anyway. And it's useful is some strange places (for example in KVM/VMWare/Xen).
The whole point though is that NFS and CIFS are unsuitable for some uses. This is where Object based file systems come in , they are like a stripped down form of NFS/CIFS.
Ideally it'd be nice to have a nice layer setup that allows people to see the layers they want and not have to put up with the layers they don't need.
One downside I see for object based file systems is with versioning file systems , which use the layout of the block layer to make having multiple versions cheap in space. That's a trade off though that may be worth it to some and not to others.
(
Log in to post comments)