On Monday 27 August 2007, Johan Adolfsson wrote:
Wouldn't we get reduced wearing and possibly a general speed up as well,
if we made sure sed was buffering stuff more and avoiding small writes
to the filesystem?
Then there shouldn't be much difference in flash wearing compared to a
copy.
any
On Sunday 26 August 2007, Cristian Ionescu-Idbohrn wrote:
On Sun, 26 Aug 2007, Denys Vlasenko wrote:
I think that sed creates new file, fills it and and then renames
new file into old file so fast that first metadata update doesn't
even have time to hit the disk storage before it's all
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Cristian
Ionescu-Idbohrn
Sent: den 26 augusti 2007 23:21
To: busybox@busybox.net
Subject: Re: [rfc] sed option `-i' (edit in place)
On Sun, 26 Aug 2007, Denys Vlasenko wrote:
On Sunday 26
On Saturday 25 August 2007 23:10, Cristian Ionescu-Idbohrn wrote:
AFAICS, that option creates a temporary file on the same fs as the edited
file resides on. And that is indeed optimal, but at the same time
somewhat unfortunate for embedded systems.
Embedded systems usualy place editable
On Sun, 26 Aug 2007, Denys Vlasenko wrote:
On Saturday 25 August 2007 23:10, Cristian Ionescu-Idbohrn wrote:
AFAICS, that option creates a temporary file on the same fs as the edited
file resides on. And that is indeed optimal, but at the same time
somewhat unfortunate for embedded
On Sunday 26 August 2007 16:00, Cristian Ionescu-Idbohrn wrote:
Embedded systems usualy place editable files on flash fs and those fs
get used out very much faster compared to real hdfs.
I think that sed creates new file, fills it and and then renames
new file into old file so fast that
On Sun, 26 Aug 2007, Denys Vlasenko wrote:
On Sunday 26 August 2007 16:00, Cristian Ionescu-Idbohrn wrote:
Embedded systems usualy place editable files on flash fs and those
fs get used out very much faster compared to real hdfs.
I think that sed creates new file, fills it and and then
AFAICS, that option creates a temporary file on the same fs as the edited
file resides on. And that is indeed optimal, but at the same time
somewhat unfortunate for embedded systems.
Embedded systems usualy place editable files on flash fs and those fs get
used out very much faster compared to
