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
nmount_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 <c...@fb.com> wrote:
> On 24 Apr 2018, at 20:35, Jayashree Mohan wrote:
>
>> Hi,
>>
>> While investigating crash con
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
://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 "unsubs
Mohan
On Wed, Feb 21, 2018 at 8:23 PM, Jayashree Mohan
<jayashree2...@gmail.com> 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 cou
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,
> >
>
.
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
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 message
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
<jayashree2...@gmail.com> wrote:
> Hi,
&g
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 majordomo inf
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
<ce3g8...@umail.furryterror.org> wrote:
>
> On Mon, Apr 16, 2018 at 09:35:24AM -0500, Jayashree Mohan w
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
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
<jayashree2...@gmail.com> wrote:
> Hi,
>
> The following seems to be a crash consistency bug on btrfs, where in
&
-
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 <fdman...@kernel.org> wrote:
> On
15 matches
Mail list logo