All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Masover <ninja@slaphack.com>
To: Mike Benoit <ipso@snappymail.ca>
Cc: Hans Reiser <reiser@namesys.com>,
	reiserfs-list@namesys.com,
	Alexander Zarochentcev <zam@namesys.com>,
	vs <vs@thebsh.namesys.com>
Subject: Re: reiser4 status (correction)
Date: Sat, 22 Jul 2006 15:37:04 -0500	[thread overview]
Message-ID: <44C28C70.3010407@slaphack.com> (raw)
In-Reply-To: <1153598173.6659.219.camel@ipso.snappymail.ca>

Mike Benoit wrote:

> code. Even just compressing that small portion though I could probably
> save between 5-10GB. The difference is though I can do a df before, and
> a df after, and I can instantly see I got my moneys worth. Same with
> encryption. 

In the case of encryption, it's also got competition.  There are two 
FUSE filesystems that do crypto, and there's cryptoloop/dm-crypt, which 
you need anyway for encrypted swap.

True, it's nowhere near as nice, but it is functional.  You would think 
one of these would be easier to develop to where it's useful.  And if 
you're encrypting it, you're already accepting a performance hit.

So again, the Reiser4 advantage here is all speed.

> http://parallel.vub.ac.be/~johan/compFUSEd/index.php?option=polls&task=results&pollid=31

Of course they are, or they wouldn't use FUSE.

But if that's really true, why wouldn't a FUSE driver help you?

> Most of those FUSE file systems you linked to scare me. This is from the
> APFS web page:

> I have lost all my data! How do I get it back?
> From the backup, obviously."

To be fair, that's what you get from any FS.

But how hard would it be to make a FUSE filesystem work properly?  How 
hard would it be to get a Reiser4 plugin to work properly?

> FUSE is great, but can it even come close to matching the performance of
> in-kernel file systems?

Performance again!

> Not only that, but if you want to compress a
> directory you have to go through about a 12 step process of moving the
> files, setting up a mount point, and moving the files back. 

You listed 3 steps.  Besides, I don't see anything stopping you from 
modifying one of these to selectively compress things, the way Reiser4 
would.  So, put your entire FS under a FUSE system, then configure which 
directories you want compressed.

Again, the drawback is huge gobs of performance.  It just seems natural 
to use the repacker if you're going to use any Reiser4-based replacement 
for these.

> You could, and we did charge by the megabyte, only after they exceeded
> the limit of their package. However web hosting is a fiercely
> competitive market, so we were constantly adjusting our packages to
> include more disk space, more bandwidth, more features for the same
> amount, or lower prices, just to compete. The way many "shared hosting"
> companies work is each server is waaay over sold, at least in the disk

Ah, so I guess the advantage of a more expensive, dedicated box is that 
you know no one's overselling it?

Personally, I get a little sick of the insane amounts of overselling 
that happen -- you just know it's going to come back and bite you in the 
ass.  This is happening right now with bandwidth, and overselling is 
pretty much solely responsible for the whole Net Neutrality mess -- it 
would be a complete non-issue if "5 megabits to your house!!!!!" was 
backed up by an actual 5 megabits reserved for me, or if they sold them 
as "2-5 megabits", where 2 is guaranteed, and 5 is what you get when no 
one else is using it.

I'm a bit skeptical of my local ISP's Fiber To The Home initiative, 
because I can't imagine they have enough spare upstream bandwidth just 
lying around.

I mean, if you actually have enough bandwidth, you don't want or need 
your ISP to do QoS or prioritizing for you -- you can just do it 
yourself.  Personally, ssh packets would be of a much higher priority to 
me than anything else...

> Thats pretty much the only way you make money with $10-20/month
> packages.

Yeah, I know, hard for an honest guy to compete...

> I don't doubt the benefits of the repacker, but from a business
> perspective the repacker is something that runs transparently in the
> background, once you install it, things magically speed up then you
> never hear from it again as it does its job. Out of sight, out of mind.
> Whereas the compression/encryption plugin are always in your face, every
> time you run df, or enter a passphrase to gain access to your files, you
> know its there and working. Its something you'll tell your friends
> about. After you first run it, the repacker just fades away in to the
> background and you forget about it.

Ah.  This might explain the success of things like Ruby On Rails.  Once 
it's done, the insane amount of CPU required to run a high-level 
interpreted language (versus even something semi-interpreted like perl) 
is out of sight, out of mind.  But when you first set it up, the savings 
in development time are immediately obvious, in your face.

Although I would want to find a way to avoid typing a passphrase every 
time -- maybe keep the key on a USB keychain.  Passphrases would just 
annoy users.  Unless, of course, you could tie it to logon -- assuming 
you can actually change the passphrase later...

> Charging only for commercial use of the repacker/compression/encryption
> plugin would be a great middle ground. 

Good, I'm glad it wasn't a completely insane idea.

  reply	other threads:[~2006-07-22 20:37 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-20 21:59 reiser4 status (correction) Hans Reiser
2006-07-21  3:02 ` David Masover
2006-07-21  8:44   ` Hans Reiser
2006-07-21 10:17     ` Sarath Menon
2006-07-21 19:13     ` David Masover
2006-07-21 20:41     ` Mike Benoit
2006-07-21 21:06       ` David Masover
2006-07-21 21:37         ` Mike Benoit
2006-07-21 22:29           ` Andreas Schäfer
2006-07-21 22:45             ` David Masover
2006-07-21 23:06               ` Andreas Schäfer
2006-07-22 20:07                 ` Maciej Sołtysiak
2006-07-21 22:40           ` David Masover
2006-07-21 23:53             ` Mike Benoit
2006-07-22  2:48               ` David Masover
2006-07-22  5:53                 ` Hans Reiser
2006-07-22  8:55                   ` Mike Benoit
2006-07-22 12:34                     ` David Masover
2006-07-22 19:56                       ` Mike Benoit
2006-07-22 20:37                         ` David Masover [this message]
2006-07-23  6:19                         ` Hans Reiser
2006-07-22 15:40                 ` portage tree (Was: Re: reiser4 status (correction)) Christian Trefzer
2006-07-23  5:50                   ` Hans Reiser
2006-07-24 15:12                     ` wiki entry (Was: Re: portage tree) Christian Trefzer
2006-07-22  0:49       ` reiser4 status (correction) Hans Reiser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=44C28C70.3010407@slaphack.com \
    --to=ninja@slaphack.com \
    --cc=ipso@snappymail.ca \
    --cc=reiser@namesys.com \
    --cc=reiserfs-list@namesys.com \
    --cc=vs@thebsh.namesys.com \
    --cc=zam@namesys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.