Re: [dev] JFS filesystem

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. So

Re: [dev] JFS filesystem

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 journ

Re: [dev] [st] bug?

On Sun, Apr 21, 2019 at 08:29:54AM +0300, Dennis Yurichev wrote: > I probably hit a bug in st, or maybe not. > I run st, then do ssh to a remote host, there is a mutt inside of tmux. > And sometimes st silently exits. > Under gdb, I can see this: BTW, found simpler solution: sudo apt remove font

Re: [dev] JFS filesystem

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 wrot

Re: [dev] JFS filesystem

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

Re: [dev] [st] bug?

On 4/21/19 10:02 AM, Dennis Yurichev wrote: > And so how to fix this? > This bug was recently fixed in dwm with a workaround that prevents loading of color fonts: https://git.suckless.org/dwm/commit/cb3f58ad06993f7ef3a7d8f61468012e2b786cab.html To fix this, you need to port this patch to st.

Re: [dev] JFS filesystem

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 cd

Re: [dev] JFS filesystem

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 > > resour

Re: [dev] JFS filesystem

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 a

Re: [dev] JFS filesystem

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. Here

Re: [dev] JFS filesystem

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: > > https://fmad.io/blog-10g-

Re: [dev] JFS filesystem

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 course

Re: [dev] JFS filesystem

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 corrections,

Re: [dev] [st] bug?

> > st uses xft font and xft is known to crash with color emoji. > > And so how to fix this? > This was discussed at length many times before on this ML; I suggest checking the online archives: https://duckduckgo.com/html/?q=site:lists.suckless.org+xft+emoji -- wowaname

Re: [dev] JFS filesystem

niedz., 21 kwi 2019 o 16:13 Martin Tournoij napisał(a): > > On Sun, 21 Apr 2019 14:53:19 +0200 Daniel Cegiełka > wrote: > > ZFS, btrfs and bcachefs are, however, designed as a filesystems for data > > storage. > > These are good filesystems for databases. Next to this is the daily > > work, whe

Re: [dev] JFS filesystem

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 > > essent

Re: [dev] JFS filesystem

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 create

Re: [dev] JFS filesystem

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 fo

Re: [dev] JFS filesystem

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 > > essent

Re: [dev] JFS filesystem

> 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. I

Re: [dev] JFS filesystem

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

Re: [dev] JFS filesystem

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.

Re: [dev] JFS filesystem

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

Re: [dev] JFS filesystem

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

Re: [dev] [st] bug?

On April 21, 2019 5:29:54 AM UTC, Dennis Yurichev wrote: >Dear suckless users, > >I probably hit a bug in st, or maybe not. >I run st, then do ssh to a remote host, there is a mutt inside of tmux. >And sometimes st silently exits. >Under gdb, I can see this: > >== >Starting program: /usr/local/bin

Re: [dev] [st] bug?

On Sun, Apr 21, 2019 at 06:32:45AM +, Danh Doan wrote: > Lemme guess, the email opened by Mutt has a color emoji. > > And you have a colored emoji font installed. Probably that was spam message... > st uses xft font and xft is known to crash with color emoji. And so how to fix this? -- --