Re: Rename+crash behaviour of btrfs - nearly ext3!

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* [Chris Mason] 

> I'm more than open to discussion on this one, but I don't see how:
>
> rm -f foo2
> dd if=/dev/zero of=foo bs=1M count=1000
> mv foo foo2
>
> Should be expected to write 1GB of data.

IIRC, the answer you're looking for is "it did with ext3 in the default
data=ordered mode".  Combine that with the ext3 data=ordered fsync()
escalation where (again IIRC) fsync() tended to force a full sync() of
the file system, and it's not that difficult to see why someone would
program with the expectation above.

Anyway, there's still a question of if a new file system should emulate
the quirks of the old file system (read: be bug compatible), or if you
can just expect to be popular enough that userspace adapts to the new
order and lets you do The Right Thing instead.

Øystein
-- 
Outgoing mail is certified Virus Free.
..of course, the virus would tell you the same thing..

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux