On Tue, Jan 30, 2018 at 4:05 AM, Jeff Layton wrote:
>
> My intent here was to have this handle wraparound using the same sort of
> method that the time_before/time_after macros do. Obviously, I didn't
> document that well.
Oh, the intent was clear. The implementation was wrong.
Note that "time_b
On Tue, Jan 30, 2018 at 07:05:48AM -0500, Jeff Layton wrote:
>
> I want to make sure I understand what's actually broken here thoug. Is
> it only broken when the two values are more than 2**63 apart, or is
> there something else more fundamentally wrong here?
The other problem is that returning a
On Mon, 2018-01-29 at 13:50 -0800, Linus Torvalds wrote:
> On Mon, Jan 29, 2018 at 4:26 AM, Jeff Layton wrote:
> >
> > This pile of patches is a rework of the inode->i_version field. We have
> > traditionally incremented that field on every inode data or metadata
> > change. Typically this increm
On Mon, Jan 29, 2018 at 1:50 PM, Linus Torvalds
wrote:
>
> Hmm. I have pulled this, but it is really really broken in one place,
> to the degree that I always went "no, I won't pull this garbage".
always=almost.
I'd blame auto-correct, but I'm not on the phone.
Linus
On Mon, Jan 29, 2018 at 4:26 AM, Jeff Layton wrote:
>
> This pile of patches is a rework of the inode->i_version field. We have
> traditionally incremented that field on every inode data or metadata
> change. Typically this increment needs to be logged on disk even when
> nothing else has changed,
5 matches
Mail list logo
