Jamie Lokier wrote:
Jeff Garzik wrote:
Nick Piggin wrote:
Anyway, the idea of making fsync/fdatasync etc. safe by default is
a good idea IMO, and is a bad bug that we don't do that :(
Agreed... it's also disappointing that [unless I'm mistaken] you have
to hack each filesystem to support
On Tue, 26 February 2008 17:29:13 +, Jamie Lokier wrote:
>
> You're right. Though, doesn't normal page writeback enqueue the COW
> metadata changes? If not, how do they get written in a timely
> fashion?
It does. But this is not sufficient to guarantee that the pages in
question have been
Jörn Engel wrote:
> On Tue, 26 February 2008 15:28:10 +, Jamie Lokier wrote:
> >
> > > One interesting aspect of this comes with COW filesystems like btrfs or
> > > logfs. Writing out data pages is not sufficient, because those will get
> > > lost unless their referencing metadata is written
On Tue, 26 February 2008 15:28:10 +, Jamie Lokier wrote:
>
> > One interesting aspect of this comes with COW filesystems like btrfs or
> > logfs. Writing out data pages is not sufficient, because those will get
> > lost unless their referencing metadata is written as well. So either we
> >
Jeff Garzik wrote:
> Nick Piggin wrote:
> >Anyway, the idea of making fsync/fdatasync etc. safe by default is
> >a good idea IMO, and is a bad bug that we don't do that :(
>
> Agreed... it's also disappointing that [unless I'm mistaken] you have
> to hack each filesystem to support barriers.
>
Nick Piggin wrote:
Anyway, the idea of making fsync/fdatasync etc. safe by default is
a good idea IMO, and is a bad bug that we don't do that :(
Agreed... it's also disappointing that [unless I'm mistaken] you have
to hack each filesystem to support barriers.
It seems far easier to make
On Tue, 26 Feb 2008 15:07:45 + Jamie Lokier <[EMAIL PROTECTED]> wrote:
> SYNC_FILE_RANGE_WRITE scans all pages in the range, looking for dirty
> pages which aren't already queued for write-out. It marks those with
> a "write-out" flag, and starts write I/Os at some unspecified time in
> the
Ric Wheeler wrote:
> >>I was surprised that fsync() doesn't do this already. There was a lot
> >>of effort put into block I/O write barriers during 2.5, so that
> >>journalling filesystems can force correct write ordering, using disk
> >>flush cache commands.
> >>
> >>After all that effort, I was
Jörn Engel wrote:
> On Tue, 26 February 2008 20:16:11 +1100, Nick Piggin wrote:
> > Yeah, sync_file_range has slightly unusual semantics and introduce
> > the new concept, "writeout", to userspace (does "writeout" include
> > "in drive cache"? the kernel doesn't think so, but the only way to
> >
Jeff Garzik wrote:
Jamie Lokier wrote:
By durable, I mean that fsync() should actually commit writes to
physical stable storage,
Yes, it should.
I was surprised that fsync() doesn't do this already. There was a lot
of effort put into block I/O write barriers during 2.5, so that
Jörn Engel wrote:
> On Tue, 26 February 2008 20:16:11 +1100, Nick Piggin wrote:
> >
> > Yeah, sync_file_range has slightly unusual semantics and introduce
> > the new concept, "writeout", to userspace (does "writeout" include
> > "in drive cache"? the kernel doesn't think so, but the only way to
On Tue, 26 February 2008 20:16:11 +1100, Nick Piggin wrote:
>
> Yeah, sync_file_range has slightly unusual semantics and introduce
> the new concept, "writeout", to userspace (does "writeout" include
> "in drive cache"? the kernel doesn't think so, but the only way to
> make sync_file_range
Jeff Garzik wrote:
> [snip huge long proposal]
>
> Rather than invent new APIs, we should fix the existing ones to _really_
> flush data to physical media.
Btw, one reason for the length is the current block request API isn't
sufficient even to make fsync() durable with _no_ new APIs.
It
On Tuesday 26 February 2008 18:59, Jamie Lokier wrote:
> Andrew Morton wrote:
> > On Tue, 26 Feb 2008 07:26:50 + Jamie Lokier <[EMAIL PROTECTED]>
wrote:
> > > (It would be nicer if sync_file_range()
> > > took a vector of ranges for better elevator scheduling, but let's
> > > ignore that :-)
Andrew Morton wrote:
> On Tue, 26 Feb 2008 07:26:50 + Jamie Lokier <[EMAIL PROTECTED]> wrote:
>
> > (It would be nicer if sync_file_range()
> > took a vector of ranges for better elevator scheduling, but let's
> > ignore that :-)
>
> Two passes:
>
> Pass 1: shove each of the segments into
Andrew Morton wrote:
On Tue, 26 Feb 2008 07:26:50 + Jamie Lokier [EMAIL PROTECTED] wrote:
(It would be nicer if sync_file_range()
took a vector of ranges for better elevator scheduling, but let's
ignore that :-)
Two passes:
Pass 1: shove each of the segments into the queue with
On Tuesday 26 February 2008 18:59, Jamie Lokier wrote:
Andrew Morton wrote:
On Tue, 26 Feb 2008 07:26:50 + Jamie Lokier [EMAIL PROTECTED]
wrote:
(It would be nicer if sync_file_range()
took a vector of ranges for better elevator scheduling, but let's
ignore that :-)
Two
Jeff Garzik wrote:
[snip huge long proposal]
Rather than invent new APIs, we should fix the existing ones to _really_
flush data to physical media.
Btw, one reason for the length is the current block request API isn't
sufficient even to make fsync() durable with _no_ new APIs.
It offers
On Tue, 26 February 2008 20:16:11 +1100, Nick Piggin wrote:
Yeah, sync_file_range has slightly unusual semantics and introduce
the new concept, writeout, to userspace (does writeout include
in drive cache? the kernel doesn't think so, but the only way to
make sync_file_range safe is if you
Jörn Engel wrote:
On Tue, 26 February 2008 20:16:11 +1100, Nick Piggin wrote:
Yeah, sync_file_range has slightly unusual semantics and introduce
the new concept, writeout, to userspace (does writeout include
in drive cache? the kernel doesn't think so, but the only way to
make
Jeff Garzik wrote:
Jamie Lokier wrote:
By durable, I mean that fsync() should actually commit writes to
physical stable storage,
Yes, it should.
I was surprised that fsync() doesn't do this already. There was a lot
of effort put into block I/O write barriers during 2.5, so that
Jörn Engel wrote:
On Tue, 26 February 2008 20:16:11 +1100, Nick Piggin wrote:
Yeah, sync_file_range has slightly unusual semantics and introduce
the new concept, writeout, to userspace (does writeout include
in drive cache? the kernel doesn't think so, but the only way to
make
Ric Wheeler wrote:
I was surprised that fsync() doesn't do this already. There was a lot
of effort put into block I/O write barriers during 2.5, so that
journalling filesystems can force correct write ordering, using disk
flush cache commands.
After all that effort, I was very surprised to
On Tue, 26 Feb 2008 15:07:45 + Jamie Lokier [EMAIL PROTECTED] wrote:
SYNC_FILE_RANGE_WRITE scans all pages in the range, looking for dirty
pages which aren't already queued for write-out. It marks those with
a write-out flag, and starts write I/Os at some unspecified time in
the near
Nick Piggin wrote:
Anyway, the idea of making fsync/fdatasync etc. safe by default is
a good idea IMO, and is a bad bug that we don't do that :(
Agreed... it's also disappointing that [unless I'm mistaken] you have
to hack each filesystem to support barriers.
It seems far easier to make
Jeff Garzik wrote:
Nick Piggin wrote:
Anyway, the idea of making fsync/fdatasync etc. safe by default is
a good idea IMO, and is a bad bug that we don't do that :(
Agreed... it's also disappointing that [unless I'm mistaken] you have
to hack each filesystem to support barriers.
It
On Tue, 26 February 2008 15:28:10 +, Jamie Lokier wrote:
One interesting aspect of this comes with COW filesystems like btrfs or
logfs. Writing out data pages is not sufficient, because those will get
lost unless their referencing metadata is written as well. So either we
have to
Jörn Engel wrote:
On Tue, 26 February 2008 15:28:10 +, Jamie Lokier wrote:
One interesting aspect of this comes with COW filesystems like btrfs or
logfs. Writing out data pages is not sufficient, because those will get
lost unless their referencing metadata is written as well.
On Tue, 26 February 2008 17:29:13 +, Jamie Lokier wrote:
You're right. Though, doesn't normal page writeback enqueue the COW
metadata changes? If not, how do they get written in a timely
fashion?
It does. But this is not sufficient to guarantee that the pages in
question have been
Jamie Lokier wrote:
Jeff Garzik wrote:
Nick Piggin wrote:
Anyway, the idea of making fsync/fdatasync etc. safe by default is
a good idea IMO, and is a bad bug that we don't do that :(
Agreed... it's also disappointing that [unless I'm mistaken] you have
to hack each filesystem to support
Jeff Garzik wrote:
> Jamie Lokier wrote:
> >By durable, I mean that fsync() should actually commit writes to
> >physical stable storage,
>
> Yes, it should.
Glad we agree :-)
> >I was surprised that fsync() doesn't do this already. There was a lot
> >of effort put into block I/O write barriers
Jamie Lokier wrote:
By durable, I mean that fsync() should actually commit writes to
physical stable storage,
Yes, it should.
I was surprised that fsync() doesn't do this already. There was a lot
of effort put into block I/O write barriers during 2.5, so that
journalling filesystems can
On Tue, 26 Feb 2008 07:26:50 + Jamie Lokier <[EMAIL PROTECTED]> wrote:
> (It would be nicer if sync_file_range()
> took a vector of ranges for better elevator scheduling, but let's
> ignore that :-)
Two passes:
Pass 1: shove each of the segments into the queue with
On Tue, 26 Feb 2008 07:26:50 + Jamie Lokier [EMAIL PROTECTED] wrote:
(It would be nicer if sync_file_range()
took a vector of ranges for better elevator scheduling, but let's
ignore that :-)
Two passes:
Pass 1: shove each of the segments into the queue with
Jamie Lokier wrote:
By durable, I mean that fsync() should actually commit writes to
physical stable storage,
Yes, it should.
I was surprised that fsync() doesn't do this already. There was a lot
of effort put into block I/O write barriers during 2.5, so that
journalling filesystems can
Jeff Garzik wrote:
Jamie Lokier wrote:
By durable, I mean that fsync() should actually commit writes to
physical stable storage,
Yes, it should.
Glad we agree :-)
I was surprised that fsync() doesn't do this already. There was a lot
of effort put into block I/O write barriers during
36 matches
Mail list logo
