https://patchwork.kernel.org/patch/10120293/
[2] https://sourceforge.net/p/linux-f2fs/mailman/message/36104201/
[3] https://github.com/utsaslab/crashmonkey
Thanks,
Jayashree Mohan
2nd Year PhD in Computer Science
University of Texas at Austin.
--
To unsubscribe from this list: send the line "u
Mohan
On Wed, Feb 21, 2018 at 8:23 PM, Jayashree Mohan
wrote:
> Hi,
>
> On btrfs (as of kernel 4.15), say we fallocate a file with keep_size
> option, followed by fdatasync() or fsync(). If we now crash, on
> recovery we see a wrong block count and all the blocks allocated
&
list.
Additionally, if there are more patches queued to address these
issues, please let us know.
Thanks,
Jayashree Mohan
Thanks,
Jayashree Mohan
On Fri, May 11, 2018 at 10:45 AM Filipe Manana wrote:
>
> On Mon, Apr 30, 2018 at 5:04 PM, Vijay Chidambaram wrote:
> > Hi,
> >
>
Hi Amir,
> I went back to look at similar fsync tests by Filipe:
> generic/{106,107,335,336,341,342,343,348,498,501,502,509,510,512}
>
> I found some alleged subtle mistakes about SOMC assumptions.
>
> generic/336 does:
> touch $SCRATCH_MNT/a/foo
> ln $SCRATCH_MNT/a/foo $SCRATCH_MNT/b/foo_link
> t
tree -
however the md5 before and after crash was the same.
Could you give more details on this?
https://friendpaste.com/1wVAz7hG0U5SgYtZavbJhL
https://friendpaste.com/1wVAz7hG0U5SgYtZavxALg
Thanks,
Jayashree Mohan
On Thu, Mar 29, 2018 at 8:45 AM, Filipe Manana wrote:
> On Wed, Mar 28, 2018 at
On Mon, Apr 2, 2018 at 9:24 AM, Filipe Manana wrote:
> On Thu, Mar 29, 2018 at 7:55 PM, Jayashree Mohan
> wrote:
>> Hi Filipe,
>>
>> I tried running the xfstest above on kernel 4.15.0 and I haven't been
>> able to hit the bug. The xfstest passes clean for me.
.
Thanks,
Jayashree Mohan
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hey Dave,
Thanks for clarifying the crash recovery semantics of strictly
metadata ordered filesystems. We had a follow-up question in this
case.
On Fri, Apr 13, 2018 at 8:16 AM, Amir Goldstein wrote:
> On Fri, Apr 13, 2018 at 3:54 PM, Vijay Chidambaram
> wrote:
>> Hi Amir,
>>
>> Thanks for the
cover to the correct link count of 2
for the above workload.
Let us know what you think about this behavior.
Thanks,
Jayashree Mohan
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordom
comment on why btrfs does not exhibit this behavior, and if
it's something you'd want to fix?
Thanks,
Jayashree Mohan
On Mon, Apr 16, 2018 at 9:35 AM, Jayashree Mohan
wrote:
> Hi,
>
> The following seems to be a crash consistency bug on btrfs, where in
> the link count is not
Hi Zygo,
Thanks for the reply. Here are few responses about btrfs behavior that
you had questions about in your email.
On Thu, Apr 19, 2018 at 4:41 PM, Zygo Blaxell
wrote:
>
> On Mon, Apr 16, 2018 at 09:35:24AM -0500, Jayashree Mohan wrote:
> > Hi,
> >
> > The follo
in the
test directory. We expect directory entries to be persisted when the
directory inode is fsynced right? Losing file foo doesn't seem to be
the right behavior.
Thanks,
Jayashree Mohan
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a me
Hi,
A gentle reminder on the above behavior on btrfs : Even on fsync-ing
the directory, its entries are not persisted. Could you let us know
your thoughts on this?
Thanks,
Jayashree Mohan
On Fri, Apr 20, 2018 at 1:05 PM, Jayashree Mohan
wrote:
> Hi,
>
> We came across a scena
bove tests pass on ext4 and xfs.
Please let us know what you feel about such inconsistency.
Thanks,
Jayashree Mohan
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
nt
_unmount_flakey
Thanks for your time!
[1] https://github.com/utsaslab/crashmonkey
Thanks,
Jayashree Mohan
On Thu, Apr 26, 2018 at 11:28 AM, Chris Mason wrote:
> On 24 Apr 2018, at 20:35, Jayashree Mohan wrote:
>
>> Hi,
>>
>> While investigating crash consistency b
Thanks Chris and Ted for putting down the expected fsync behaviour of
btrfs and ext4 clearly. This sort of information is not documented
anywhere; it would be really useful if all major filesystems
explicitly stated what fsync behavior to expect. Filesystems
definitely seem to provide more guarante
Hi Jeff,
On Mon, Apr 30, 2018 at 11:51 AM, Jeff Mahoney wrote:
> On 4/30/18 12:04 PM, Vijay Chidambaram wrote:
>> Hi,
>>
>> We found two more cases where the btrfs behavior is a little strange.
>> In one case, an fsync-ed file goes missing after a crash. In the
>> other, a renamed file shows up i
17 matches
Mail list logo