Paul Eggert wrote:
You may well be right that eventually file system designers will figure
this stuff out so that well-written POSIX applications will not lose
data even if they don't use fsync/fdatasync. However, if FSCQ is any
indication, we're many years away from that. In the meantime
fsyn
On 03/01/2016 10:13 AM, Antonio Diaz Diaz wrote:
[1] http://news.mit.edu/2015/crash-tolerant-data-storage-0824
FSCQ is not even close to ready for prime-time, I'm afraid. Its
prototype is slow compared to conventional file systems (it assumes a
single-threaded kernel, it issues many more writ
Paul Eggert wrote:
I know, but how can you guarantee that 'gzip --synchronous' will work
on a system where the 'sync' above does not even guarantee that
'file.gz' is written to disk before 'file' is deleted?
Yes, I can guarantee that 'gzip --synchronous' will not lose data on any
system confo
On 02/29/2016 09:12 AM, Antonio Diaz Diaz wrote:
1) gzip --keep file # don't delete input
2) sync # commit output and directory to disk
3) zcmp file file.gz# verify output
4) rm file # then remove input
That approach does not suffice, because 'sync' does not
Paul Eggert wrote:
Feature creep is something we should avoid. Here, though, it's a real
pain to synchronize correctly and many people will get it wrong.
The problem is that it is impossible to get it right unless one does
something as extreme as unmounting-then-remounting the filesystem, or
Antonio Diaz Diaz wrote:
it may be a cause of feature creep. If gzip fsyncs the output file it
might also test it, or even compare it with the input file, before deleting the
input file.
Feature creep is something we should avoid. Here, though, it's a real pain to
synchronize correctly and ma
Antonio Diaz Diaz wrote:
ddrescue already provides the option '-y, --synchronous' for a somewhat
similar functionality.
OK, let's do it as --synchronous, long-only. If the need keeps growing we can
add -y.
Just now my preference is to make the behavior optional
On second thought, as Bob
Bob Proulx wrote:
Just now my preference is to make the behavior optional and call the option
--fsync. I think both points meet the principle of least surprise.
I would much prefer the above of an option to enable it rather than
one to disable it. Otherwise I have to go through workarounds to
Antonio Diaz Diaz wrote:
> Paul Eggert wrote:
> >And this suggests that any long option name shouldn't be something
> >syscall-specific like '--no-fsync', but should instead be something more
> >general and easy to remember, e.g., '--hasty'.
>
> I had to search 'hasty' in the dictionary, so I thin
Antonio Diaz Diaz wrote:
Just now my preference is to make the behavior optional and call the
option --fsync. I think both points meet the principle of least surprise.
An additional reason to make the behavior optional is that people find
the performance penalty of fsync so annoying that they
Paul Eggert wrote:
Why -y? And why a short name at all? I don't expect this to be
something that people will want to type by hand.
Because ddrescue already provides the option '-y, --synchronous' for a
somewhat similar functionality. (It is in my first message). I find
short option names ha
On 02/26/2016 04:34 AM, Antonio Diaz Diaz wrote:
Is it ok to use '-y' as short option name?
Why -y? And why a short name at all? I don't expect this to be
something that people will want to type by hand.
Come to think of it, gzip should also do an fsync, or at least an
fdatasync, on the d
Paul Eggert wrote:
Yes, I considered an --fsync option as well, but worried about making
the default unsafe. How about if gzip and lzip instead add a --no-fsync
option for people who don't need the safety?
I think it is a good idea. The people who know that don't need the
safety are probably
Antonio Diaz Diaz wrote:
I am considering a different approach for lzip; adding a new option, say '-y,
--fsync', to call fsync when acting in-place. This provides safety to those
needing it without slowing down the work of everybody else. Especially of those
(de)compressing a lot of replaceable f
Paul Eggert wrote:
Thanks for reporting the problem. It's annoying that gzip must invoke
fsync, as that's way overkill compared to the write-ordering that is
needed and fsync will slow gzip down, but I don't see any safe and
reasonably portable alternative
I 100% agree.
I am considering a di
Thanks for reporting the problem. It's annoying that gzip must invoke fsync, as
that's way overkill compared to the write-ordering that is needed and fsync will
slow gzip down, but I don't see any safe and reasonably portable alternative so
I installed the attached patch on Savannah, here:
htt
Hi gzip developers,
Gzip version: 1.6
I am developing a tool to validate crash safety of application software. I have
just found that the file deletion has a potential safety venerability: if only
a prefix of I/O operations are flushed to disk, after reboot, the file-system
would only contain
17 matches
Mail list logo
