[PATCH] ash: add support for history buffer

[Dennis Groenen]

On 07/13/2011 07:28 AM, Denys Vlasenko wrote:
> On Tuesday 12 July 2011 20:14, Laurent Bercot wrote:
>>> BusyBox writes to .ash_history after each and every command, which we don't
>>> want on e.g. mobile devices with a flash-based storage device.
>>> Using a buffer helps reducing the amount of erase/write cycles on the
>>> storage medium
>>   Wouldn't mobile devices with flash-based storage be better off using an
>> adapted filesystem layer, such as UBI ? Patching every application to
>> avoid writing to the filesystem does not sound like the right way to
>> handle this.
> Yes, I think the approach this patch takes is not sustainable.
I agree with both of you that patching every application is a no-go. 
However, a lot of flash based storage mediums are exposed as block 
devices nowadays, thus UBI can't always be used. I use the shell a lot, 
and going trough an erase cycle every time I press enter doesn't sound 
like an ideal situation. That's why I target BusyBox specifically.

> History is a small file. If your flash fs and hardware can't cope
> even with periodic updates of a small file, then how it copes with
> other real-world cases?
I'm sure the flash storage medium can cope with the wear caused by 
BusyBox, but this doesn't take away the point that the current behaviour 
isn't exactly ideal. Tweaking the fs might be a solution here (e.g. 
delayed writing), but this affects more than just BusyBox, which might 
not be desirable.

Other applications typically write out larger files less often than 
BusyBox does, which appears to be more efficient to me than writing out 
small files a lot (regarding wear). I'm taking those bigger writes for 
granted; I don't even want all of those writes to be cached or something.

> BTW, what about solving it with
> "ln -s /tmp/.ash_history-$USERNAME ~/.ash_history" ?
Thanks for the suggestion, but this would require me to manually copy 
history files at boot and shutdown, or write shell scripts to do this 
for me. It is much cleaner to let BusyBox itself handle this per a 
configurable option (like my patch) in my opinion.

Anyway, it's not up to me what (not) to include in BusyBox of course. I 
hope I've given a good impression on why I think this patch is 
justified. I, for one, will certainly keep using the it for my builds.
--Dennis