Daniel Cegiełka wrote:
If you have a power failure, it simply can lose data (whether
JFS or XFS).
Unfortunately I can confirm this. We've lost data twice on a
CentOS server with XFS, and once it happened on my local machine
because of a freeze.
--
caóc
pon., 22 kwi 2019 o 07:17 Fernando Cassia napisał(a):
>
> On 4/19/19, Daniel Cegiełka wrote:
>
> > Would anyone be interested to start supporting JFS? I'm thinking about
> > rewriting jfsutils.
> >
> > Best regards,
> > Daniel
>
> +1 on all your points.
>
> I ran JFS on a dual-Pentium III SMP
On Sun, 21 Apr 2019 19:41:02 +0200 Daniel Cegiełka
wrote:
> > What exactly disqualifies bcachefs as a general purpose filesystem?
>
> Kent Overstreet said he didn't test bcachefs on small setups. This is
> a filesystem designed for storage. It is therefore a competition for
> btrfs and zfs.
On Sun, Apr 21, 2019 at 8:42 PM Daniel Cegiełka
wrote:
>
> https://www.patreon.com/bcachefs
I've just taken a look at https://bcachefs.org/ and from what I see it
tries to be a "do-all" file-system going the route of ZFS and BTRFS,
from RAID and multiple drives to compression and encryption.
On Mon, Apr 22, 2019 at 12:10 AM Daniel Cegiełka
wrote:
> An interesting solution is to keep JFS metadata on a fast separate
> ssd. Then on the main disk you have only data structures that can be
> recovered more easily.
I find it a terrible idea (for non enterprise deployments) to put the
On 4/19/19, Daniel Cegiełka wrote:
> Would anyone be interested to start supporting JFS? I'm thinking about
> rewriting jfsutils.
>
> Best regards,
> Daniel
+1 on all your points.
I ran JFS on a dual-Pentium III SMP system for nearly five years. With
excellent performance.
Ten years ago I
niedz., 21 kwi 2019 o 21:55 Ciprian Dorin Craciun
napisał(a):
>
> On Sun, Apr 21, 2019 at 8:42 PM Daniel Cegiełka
> > The best example here is Google. They used ext2 for a long time as
> > their main filesystem. Yes, ext2. Why? ext2 is a very simple file
> > system - it is light and fast. One of
niedz., 21 kwi 2019 o 21:10 stephen Turner
napisał(a):
>
> I am an amateur here and follow mostly to learn from you all, but I did like
> some of the ideas in btrfs.
my tricks with btrfs (no partitions):
dd if=/dev/zero of=/dev/sda bs=4096
mkfs.btrfs -L dev_sda /dev/sda
mount /dev/sda /mnt
niedz., 21 kwi 2019 o 22:07 Ciprian Dorin Craciun
napisał(a):
>
> On Sat, Apr 20, 2019 at 1:29 AM Daniel Cegiełka
> wrote:
> > * JFS [1]
> > Forgotten file system. JFS is what ext4 should be. This is a very well
> > thought and well-designed file system. It is very light and has a tiny
> >
niedz., 21 kwi 2019 o 21:55 Ciprian Dorin Craciun
napisał(a):
>
>
> Indeed, Git is the best "file-system" (if it can be called so) for
> important data. (It even has `git-fsck`.) :)
>
> Moreover I usually keep (and generate once in a while) MD5 checksums
> of all my files, which, coupled with
On Sat, Apr 20, 2019 at 1:29 AM Daniel Cegiełka
wrote:
> * JFS [1]
> Forgotten file system. JFS is what ext4 should be. This is a very well
> thought and well-designed file system. It is very light and has a tiny
> resource consumption. The first journaling file system plus unicode
> support.
On Sun, Apr 21, 2019 at 8:42 PM Daniel Cegiełka
wrote:
> allocate to ext4+RAID (md) a large block of memory (fallocate). Then
> use this block of memory as a huge ring buffer and they simply copy
> memory using mmap. Of course, data integrity is checked at every step:
>
>
On Sun, Apr 21, 2019 at 8:42 PM Daniel Cegiełka
wrote:
> We have three main purpose filesystems:
> * reading - Speed is the key here.
> * writing - This is a very complex issue. Write operations should be
> atomic (see Raiser4). Data integrity should be checked at the memory
> level. And of
I am an amateur here and follow mostly to learn from you all, but I did like
some of the ideas in btrfs. Being able to add ssd’s for “cache” with spinning
disks for long term and the system manage moving the data between the two based
on use, auto repairs during use, data checks and
niedz., 21 kwi 2019 o 15:24 Joseph Graham napisał(a):
>
> > In fact, in many filesystems there are very weak – or no! – guarantees that
> > the data you're reading is actually correct. Systems like ext4 simply assume
> > that the data written to the disk will never change. AFAIK, it has
> >
niedz., 21 kwi 2019 o 12:48 Igor Rubel napisał(a):
>
> Hello!
>
> What do you think about union mounting and UnionFS in particular?
I really like this idea. This is the Plan 9's bind implementation. You
can mount many different sources in one directory. Imagine that your
login program also
niedz., 21 kwi 2019 o 14:35 Martin Tournoij napisał(a):
>
> On Fri, 19 Apr 2019 09:20:41 +0200 Daniel Cegiełka
> wrote:
> > * ZFS
> > Resource-consuming. Designed for large servers.
> >
> > * btrfs
> > Rather a good choice for server rooms (Facebook).
> >
> > * bcachefs
> > A good competition
On Sun, 21 Apr 2019 14:21:27 +0100 Joseph Graham wrote:
> > In fact, in many filesystems there are very weak – or no! – guarantees that
> > the data you're reading is actually correct. Systems like ext4 simply assume
> > that the data written to the disk will never change. AFAIK, it has
> >
> In fact, in many filesystems there are very weak – or no! – guarantees that
> the data you're reading is actually correct. Systems like ext4 simply assume
> that the data written to the disk will never change. AFAIK, it has
> essentially no mechanism at all to deal with silent data corruption.
niedz., 21 kwi 2019 o 14:44 Alexander Huemer
napisał(a):
>
> I have used JFS on Linux for several years, the experience was not
> positive. Under conditions like 'disk full' or 'power failure' it tends
> to corrupt data. I have also worked with JFS on AIX, over there the same
> issues do not seem
I have used JFS on Linux for several years, the experience was not
positive. Under conditions like 'disk full' or 'power failure' it tends
to corrupt data. I have also worked with JFS on AIX, over there the same
issues do not seem to exist. Be cautious to use it for anything serious
on Linux.
On Fri, 19 Apr 2019 09:20:41 +0200 Daniel Cegiełka
wrote:
> * ZFS
> Resource-consuming. Designed for large servers.
>
> * btrfs
> Rather a good choice for server rooms (Facebook).
>
> * bcachefs
> A good competition for btrfs/ZFS.
One thing that ZFS offers that most other filesystems don't is
Hello!
What do you think about union mounting and UnionFS in particular?
Regards,
I. Rubel
> On 19. Apr 2019, at 07:20, Daniel Cegiełka wrote:
>
> Hi,
>
> I know that most people on this list use ext4 - Michael's oasis,
> sta.li etc. We simply take ext4 and do not consider other options. I
Hi,
I know that most people on this list use ext4 - Michael's oasis,
sta.li etc. We simply take ext4 and do not consider other options. I
don't want to start discussing which file system is the best and the
fastest, because it depends on the destination. I'm interested in
which file system sucks
24 matches
Mail list logo
