On Wed, May 15, 2019 at 10:02 AM wrote:
>
> From: Filipe Manana
>
> Run fsstress, fsync every file and directory, simulate a power failure and
> then verify the all files and directories exist, with the same data and
> metadata they had before the power failure.
I'm happy to see this sort of cra
On Thu, Mar 7, 2019 at 10:35 PM Dave Chinner wrote:
>
> On Thu, Mar 07, 2019 at 05:19:51PM -0600, Jayashree Mohan wrote:
> > 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 all
On Mon, Mar 4, 2019 at 7:00 PM Dave Chinner wrote:
>
> On Tue, Mar 05, 2019 at 11:50:20AM +1100, Dave Chinner wrote:
> > On Mon, Mar 04, 2019 at 05:04:23PM +0200, Amir Goldstein wrote:
> > > On Mon, Mar 4, 2019 at 4:44 PM wrote:
> > > >
> > > > From: Filipe Manana
> > > >
> > > > Test that if we
On Mon, Apr 30, 2018 at 11:56 AM, Jayashree Mohan
wrote:
> 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
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 in both directories after a crash.
Workload 1:
mkdir A
mkdir B
mkdir A/C
creat B/foo
fsync B/foo
link B/foo A/C/foo
fsync A
--
On Sun, Apr 29, 2018 at 5:16 PM, Theodore Y. Ts'o wrote:
> On Sun, Apr 29, 2018 at 03:55:39PM -0500, Vijay Chidambaram wrote:
>> In the spirit of clarifying fsync behavior, we have one more case
>> where we'd like to find out what should be expected.
>>
>> Co
> On Fri, Apr 27, 2018 at 3:53 PM, Theodore Y. Ts'o wrote:
>> On Fri, Apr 27, 2018 at 11:33:29AM -0600, Chris Mason wrote:
>>> My goal for the fsync tree log was to make it just do the right thing most
>>> of the time. We mostly got there, thanks to a ton of fixes and test cases
>>> from Filipe.
Hi all,
Any thoughts on this?
We completely understand you are all busy and might be traveling, so
we only need a simple ack from you: that when we fsync a directory in
btrfs, we can expect the contents to get persisted. We understand that
is not your highest priority item, and that you will fix
On Mon, Apr 16, 2018 at 7:07 PM, Dave Chinner wrote:
> On Sun, Apr 15, 2018 at 07:10:52PM -0500, Vijay Chidambaram wrote:
>> Thanks! As I mentioned before, this is useful. I have a follow-up
>> question. Consider the following workload:
>>
>> creat foo
>>
On Mon, Apr 16, 2018 at 12:39 AM, Amir Goldstein wrote:
> On Mon, Apr 16, 2018 at 3:10 AM, Vijay Chidambaram
> wrote:
> [...]
>> Consider the following workload:
>>
>> creat foo
>> link (foo, A/bar)
>> fsync(foo)
>> crash
>>
>> I
On Mon, Apr 16, 2018 at 12:52 AM, Theodore Y. Ts'o wrote:
> On Sun, Apr 15, 2018 at 07:10:52PM -0500, Vijay Chidambaram wrote:
>>
>> I don't think this is what the paper's ext3-fast does. All the paper
>> says is if you have a file system where the fsync of a
BSD and other
> Unix systems, as well as Linux.
Thanks! As I mentioned before, this is useful. I have a follow-up
question. Consider the following workload:
creat foo
link (foo, A/bar)
fsync(foo)
crash
In this case, after the file system recovers, do we expect foo's link
count to be
Hi Ted,
On Sat, Apr 14, 2018 at 8:30 PM, Theodore Y. Ts'o wrote:
> When you open "foo", the restulting file descriptor is not associated
> with the symlink. The resulting file descriptor is the exact same
> thing you would get if you had instead called:
>
> fd = open("/tmp/bar/quux", O_C
ed
I don't disagree with any of this. But you can imagine how this can be
all be confusing to file-system developers and research groups who
work on file systems: without formal documentation, what exactly
should they test or support? Clearly current file systems provide more
than just POSI
) -> fails
but
fd = open(symlink, O_CREAT|O_RDWR) -> succeeds (even if symlink already exists)
fsync(fd) -> succeeds
So perhaps fsync on "symlink" is unsupported behavior that varies from
file system to file system? We saw ext4 and xfs had this behavior, so
we assumed it to
t;
>> 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
&
; like this:
>
>
> 1. symlink (foo, bar.tmp)
> 2. open bar.tmp
> 3. fsync bar.tmp
> 4. rename(bar.tmp, bar)
> 5. fsync bar
> crash here
I'm guessing xfs/ext4 detect the symlink-fsync pattern and fsync the
parent dir in our workload, but would miss it because of
ent, so that we
don't make any decisions that will prevent us from going the DM target
route later.
Thanks,
Vijay
On Wed, Aug 16, 2017 at 3:27 PM, Amir Goldstein wrote:
> On Wed, Aug 16, 2017 at 10:06 PM, Vijay Chidambaram
> wrote:
>> Hi Josef,
>>
>> Thank you f
like Ari will try out
CrashMonkey in its current form, which will guide us as to what
functionality to add to CrashMonkey to find bugs more effectively.
Thanks,
Vijay
On Wed, Aug 16, 2017 at 8:06 AM, Josef Bacik wrote:
> On Tue, Aug 15, 2017 at 08:44:16PM -0500, Vijay Chidambaram wrote:
&g
19 matches
Mail list logo
