[opensuse] Opensuse on a usb flash disk: installation and partitioning advice needed
Hello, new to OpenSuse but not new to Linux (10+ years plus some BSD experience). I am thinking of having a go at OpenSuse and I was thinking of installing it on a 16GB flash drive to play with it before transferring it onto a partition on my old Thinkpad (64bit). Is there anything I should know before installation? Which is the best filesystem? Ext2, Ext4 without journalling or other? What's a recommended partitioning layout in case I want to keep my applications but reinstall the base system one day? Does the live image support persistent settings? Thanks. -- Ottavio -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-11 15:53, Ottavio Caruso wrote:
Which is the best filesystem? Ext2, Ext4 without journalling or other?
What's a recommended partitioning layout in case I want to keep my applications but reinstall the base system one day?
With only 16 GiB, you should go for ext4 in a single partition, no /home partition. And without journalling is a good idea, too, but you will have to manually create it, I think.
Does the live image support persistent settings?
Yes, it does. But very limited updates, none to the core. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWhJf8ACgkQja8UbcUWM1zbVwD+PVleylydRzsiOWqFDqRLhIk9 1DPH2xahQPO7QOGFpA8A/jJUTD9dgGbNfIQeA2K9G/j4YpPrshPMPSSaDLkZY2XL =dtaX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11 July 2015 at 15:19, Carlos E. R.
With only 16 GiB, you should go for ext4 in a single partition, no /home partition. And without journalling is a good idea, too, but you will have to manually create it, I think.
Does the live image support persistent settings?
Yes, it does. But very limited updates, none to the core.
Thanks -- Ottavio -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/11/2015 10:19 AM, Carlos E. R. wrote:
On 2015-07-11 15:53, Ottavio Caruso wrote:
Which is the best filesystem? Ext2, Ext4 without journalling or other?
What's a recommended partitioning layout in case I want to keep my applications but reinstall the base system one day?
With only 16 GiB, you should go for ext4 in a single partition, no /home partition. And without journalling is a good idea, too, but you will have to manually create it, I think.
Does the live image support persistent settings?
Yes, it does. But very limited updates, none to the core.
My current RootFS is 12G and my /usr/share adds another 3G. Then there's /boot ... So yes, as Carlos says, not room for /home. That being said, I have put a reduced 32-bit systems with lxde, which is supposed to be lighter than xfce, on a 20G drive with 1.25G swap and a not a separate /home or /tmp. I have a 32G USB drive with a 64-but system on it, yes. Again lxde. Its more so that I can do recovery if and when my BtrFS RootFS'd main system crashes. Don't short change yourself.. You can get 32G USB drives on eBay for under US$5 in one-off quantities. They may not be Kingston class devices (which are 5 times that price or more) wrt quality&reliability but they are "good enough", as the saying goes. Stay away from the China sourced 32G SCHC chips. I've found then to have a bad block of over 15%, some as high as 45%. Some look OK on first scan but degraded once I put a FS on them and rescanned. I've some real Kingston drives and SDHC chips, the latter in my phone & in my tablet. I use Kingston 16G and 32G in my camera. That's closer to US$1/G but you don't see me arguing. I'd love it if the <$1/10G chips were reliable. I'd be using them for backup instead of DVDs :-) But go and spend the $10-$15 on a 32G USB stick and avoid the limits you've run into. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11 July 2015 at 15:52, Anton Aylward
Don't short change yourself.. You can get 32G USB drives on eBay for under US$5 in one-off quantities.
Thanks. Like I said, this would be only for a couple of weeks to play with the system. Then I would transfer it onto a proper hard drive partition. I don't really use much storage for myself. Most of my work is online. I would probably use a very minimal setup with Fluxbox, if it's to be found in the repositories. -- Ottavio -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-11 17:11, Ottavio Caruso wrote:
Like I said, this would be only for a couple of weeks to play with the system. Then I would transfer it onto a proper hard drive partition.
I have a test system on only 9 GiB, plus another partition for swap. I didn't do anything special to install it, just one desktop, preferably not kde or gnome. As I use it only for testing, there is no data stored on /home. So 32 GiB certainly suffices. Certain programs are big, like libreoffice, so I usually not install it. But the default install nowdays wants btrfs, and that needs space. On the other hand, when disk space is small, doing it all in a single partition (except swap) conserves disk space. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWhP6YACgkQja8UbcUWM1zoRwEAku16Jnoj0Vv4p0ClWbrg9zGy MRB/g4Gzt3Ws51bQUXEA+QHBuQc8q9kk/VfciDdtIHrenTu4wSWVaXhjBSbY0WDJ =pcB2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/11/2015 12:09 PM, Carlos E. R. wrote:
But the default install nowdays wants btrfs, and that needs space.
Or journals.
On the other hand, when disk space is small, doing it all in a single partition (except swap) conserves disk space.
Doing it with 32-bit helps too :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
journald can be configured to use however much persistent storage you want; it can also be configured to use only volatile storage. Btrfs uses substantially less metadata at mkfs time compared to XFS, let alone ext234. In-use the metadata usage is about the same as the others. For small volumes (maybe less than 10GiB) there's some advantage to using mixed metadata and data with -M at mkfs time. This limits nodesize so there's a bit of a performance hit, but it's more efficient and essentially eliminates the ENOSPC risk. With the smaller nodesize, small files are less likely to be written in-line with metadata, so small file efficiency is also reduced with mixed. But it's still better than other file systems. Plus, flash is notoriously non-deterministic. Your data on flash is effectively a probability function, i.e. the data the flash returns is probably your data. So having the ability to know if there are problems, even with single profile metadata (-M, mixed implies single profile for data and metadata, rather than dup for metadata) at least you get warnings, rather than SDC. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-11 18:44, Chris Murphy wrote:
journald can be configured to use however much persistent storage you want; it can also be configured to use only volatile storage.
Even when you tell it to use volatile storage, it uses a lot of disk space: minas-tirith:~ # journalctl --disk-usage Journals take up 74.3M on disk. minas-tirith:~ # uptime 19:34pm up 4 days 21:29, 25 users, load average: 0.11, 0.21, 0.20 minas-tirith:~ # ls /var/log/jo* ls: cannot access /var/log/jo*: No such file or directory minas-tirith:~ # A problem with journald is that you can not purge it of messages by classes, like erase all nntp entries. They take most of the megabytes above.
Btrfs uses substantially less metadata at mkfs time compared to XFS,
Really? I have to test that, because I know XFS takes very little. However, the big problem is snapshooting. On small rotating disks I would rather prefer reiserfs. And on flash stickes, I would prefer f2fs, when it becomes available. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWhVboACgkQja8UbcUWM1yybAD8DMM0b5sSpJoGir6TNMhkHzMq cpJXhmJ/nMSmfh4SIUAA/j8fPDDRuMvBgEGsqkyZueVElJgSBo8yoovFvYeE+tF9 =1wZn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Jul 11, 2015 at 11:43 AM, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-07-11 18:44, Chris Murphy wrote:
journald can be configured to use however much persistent storage you want; it can also be configured to use only volatile storage.
Even when you tell it to use volatile storage, it uses a lot of disk space:
minas-tirith:~ # journalctl --disk-usage Journals take up 74.3M on disk. minas-tirith:~ # uptime 19:34pm up 4 days 21:29, 25 users, load average: 0.11, 0.21, 0.20 minas-tirith:~ # ls /var/log/jo* ls: cannot access /var/log/jo*: No such file or directory minas-tirith:~ #
A problem with journald is that you can not purge it of messages by classes, like erase all nntp entries. They take most of the megabytes above.
Btrfs uses substantially less metadata at mkfs time compared to XFS,
Really? I have to test that, because I know XFS takes very little.
I've done it with qcow2 and vdi files, just format the drives in a VM and see the size of the vm files change. But it might also be possible to do this with fallocated files and formatting them directly, mkfs.btrfs will format a file, I'm not sure about the others - they may need a loopback device setup first. Btrfs writes the least metadata of any of them. On a small file system it basically writes two superblocks that are less than 16KB each. A bit more gets written on first mount as the uuid tree and space cache are created but they still use less space than XFS, and a lot less space than ext4.
However, the big problem is snapshooting.
Well, then don't snapshot. The openSUSE 13.2 default snapper behavior is kinda ridiculous. It takes many snapshots often and isn't aggressive enough at deleting them. If that's how a USB stick installation behaves, then that's sub optimal but also isn't a Btrfs ding, it's a ding against the default behavior of snapper.
And on flash stickes, I would prefer f2fs, when it becomes available.
Btrfs is already flash optimized. The catch with f2fs is that defaults rarely are properly optimized for the specific flash you're using, and the information to properly optimize isn't revealed by the flash device. So you have to know what you've got in order to get optimized results with f2fs - there's a pile of mkfs and mount time options for this. If you get them right, f2fs performance will blow away anything, including Btrfs. But that's initial performance, I'm not sure how it stacks up as the fs ages, and gets fragmented. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/11/2015 11:11 AM, Ottavio Caruso wrote:
I don't really use much storage for myself. Most of my work is online.
Backups too? You must have a lot of very inexpensive bandwidth! I don't trust any backup that resides with a company that might go bankrupt, might have the Goodwin Law grade LE come asking for a total dump. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Ottavio Caruso composed on 2015-07-11 16:11 (UTC+0100):
Like I said, this would be only for a couple of weeks to play with the system. Then I would transfer it onto a proper hard drive partition.
I don't really use much storage for myself. Most of my work is online.
I would probably use a very minimal setup with Fluxbox, if it's to be found in the repositories.
Others have been suggesting need for a lot more space than is real for users of traditional filesystems. BTRFS, the default openSUSE filesystem, is not traditional, many times more demanding of space, and too new for this user to even sample. Even if I was a BTRFS user, I wouldn't put it on a stick. By sticking with EXTx filesystems, a 16G stick should be abundantly more than ample for a few weeks of sampling with the more svelte DEs like Fluxbox, IceWM, Enlightenment, LXDE or XFCE. This system I upgraded from 320G HD to 1TB HD several months ago and in the process I raised the size of / from 10.8G to 18G. What a waste that turned out to be. / currently is 73% freespace. I have many test installations on 4.8G / partitions with 40% or more free on /. I give myself a little more cushion by going to 5.6G / partitions when using 64 bit instead of 32. Most of my 32 bit installations are on EXT3, while most 64 bit are on EXT4. None are on BTRFS. Total installation count here is unknown, but somewhere in triple digits. For my partitioning suggestion, if you have at least 2G of RAM, consider to not even bother creating swap, or if you do, keep it very small, .5G or less. For sure make separate partition for /home, maybe a small one for /user/local, and whatever you think you must have for /. Just skip using BTRFS and whatever you come up with will be sufficient for all of it on a 16G stick. Alternatively, create a /boot of as little as 100MB (more or less to taste) using EXT2 (journaling on a /boot partition is a waste - writes there a very infrequent), and put everything else on LVM using EXT4. The openSUSE installer offers great detail in both partitioning (must choose "Expert Partitioner") and package installation. Many things you won't use in a 2-3 week trial can be skipped. As I so rarely use it, I usually skip LibreOffice, as it demands a lot in both space consumption and bandwidth at updates time. If your laptop is going to be going through a router to reach the internet always, you won't need SuSEfirewall2, Apparmor or various services taking up memory or storage space. e.g.: /boot 100M EXT2 sdX1 / 7.2G EXT4 sdX2 /swap .5G (optional) sdX3 /usr/local 1G EXT4 (optional) sdX[3 or 5] /home EXT4 remainder (~5G) sdX[3, 5 or 6] -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Jul 11, 2015 at 11:34 AM, Felix Miata
BTRFS, the default openSUSE filesystem, is not traditional, many times more demanding of space, and too new for this user to even sample. Even if I was a BTRFS user, I wouldn't put it on a stick. By sticking with EXTx filesystems, a 16G stick should be abundantly more than ample for a few weeks of sampling with the more svelte DEs like Fluxbox, IceWM, Enlightenment, LXDE or XFCE.
Btrfs is perhaps demanding of space when it comes to how it allocates/deallocates chunks, when data and metadata are not mixed. In this case with a small file system there is some higher chance of a nearly full file system experiencing ENOSPC, since right now Btrfs kernel code doesn't deallocate chunks unless they're completely empty. Otherwise it takes a balance (with or without a 'usage' filter) to compel the deallocation. But in mixed mode, it's no different then other file systems. And with compression enabled, it's quite a bit more space efficient than other file systems. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Chris Murphy composed on 2015-07-11 11:51 (UTC-0600):
But in mixed mode, it's no different then other file systems. And with compression enabled, it's quite a bit more space efficient than other file systems.
Does the OP want to risk his trial period tripping over the default BTRFS snapshot configuration in his limited space, or actually using openSUSE to do the things he wants to do? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Jul 11, 2015 at 12:06 PM, Felix Miata
Chris Murphy composed on 2015-07-11 11:51 (UTC-0600):
But in mixed mode, it's no different then other file systems. And with compression enabled, it's quite a bit more space efficient than other file systems.
Does the OP want to risk his trial period tripping over the default BTRFS snapshot configuration in his limited space, or actually using openSUSE to do the things he wants to do?
Recommending the OP not use Btrfs as an indirect way to avoid the negative consequences of snapper's sub optimal default behavior is completely reasonable. But characterizing this as Btrfs itself being demanding, and Btrfs itself having a default snapshotting configuration isn't accurate. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Chris Murphy composed on 2015-07-11 12:21 (UTC-0600):
Felix Miata wrote:
Chris Murphy composed on 2015-07-11 11:51 (UTC-0600):
But in mixed mode, it's no different then other file systems. And with compression enabled, it's quite a bit more space efficient than other file systems.
Does the OP want to risk his trial period tripping over the default BTRFS snapshot configuration in his limited space, or actually using openSUSE to do the things he wants to do?
Recommending the OP not use Btrfs as an indirect way to avoid the negative consequences of snapper's sub optimal default behavior is completely reasonable. But characterizing this as Btrfs itself being demanding, and Btrfs itself having a default snapshotting configuration isn't accurate.
While what you say is true, it's likely to matter not to a first time openSUSE user unless already familiar with BTRFS and Snapper. If Snapper get's him, highly likely he will see it as openSUSE's fault, neither Snapper's nor BTRFS's. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Jul 11, 2015 at 12:44 PM, Felix Miata
Chris Murphy composed on 2015-07-11 12:21 (UTC-0600):
Felix Miata wrote:
Chris Murphy composed on 2015-07-11 11:51 (UTC-0600):
But in mixed mode, it's no different then other file systems. And with compression enabled, it's quite a bit more space efficient than other file systems.
Does the OP want to risk his trial period tripping over the default BTRFS snapshot configuration in his limited space, or actually using openSUSE to do the things he wants to do?
Recommending the OP not use Btrfs as an indirect way to avoid the negative consequences of snapper's sub optimal default behavior is completely reasonable. But characterizing this as Btrfs itself being demanding, and Btrfs itself having a default snapshotting configuration isn't accurate.
While what you say is true, it's likely to matter not to a first time openSUSE user unless already familiar with BTRFS and Snapper. If Snapper get's him, highly likely he will see it as openSUSE's fault, neither Snapper's nor BTRFS's.
That's probably true, and completely appropriate as well. For a USB stick installation, the suboptimal default configuration of snapper arguably becomes a misconfiguration. So hopefully someone's filed a bug/feature design change request under Factory. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Chris Murphy composed on 2015-07-11 13:43 (UTC-0600):
Felix Miata wrote:
...it's likely to matter not to a first time openSUSE user unless already familiar with BTRFS and Snapper. If Snapper get's him, highly likely he will see it as openSUSE's fault, neither Snapper's nor BTRFS's.
That's probably true, and completely appropriate as well. For a USB stick installation, the suboptimal default configuration of snapper arguably becomes a misconfiguration. So hopefully someone's filed a bug/feature design change request under Factory.
I don't see one: https://bugzilla.opensuse.org/buglist.cgi?chfield=[Bug%20creation]&chfieldfrom=33m&chfieldto=Now&list_id=1843048&longdesc=snapshot%20configuration%20default&longdesc_type=allwordssubstr&query_format=advanced It won't be me filing one either. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Jul 11, 2015 at 2:14 PM, Felix Miata
Chris Murphy composed on 2015-07-11 13:43 (UTC-0600):
Felix Miata wrote:
...it's likely to matter not to a first time openSUSE user unless already familiar with BTRFS and Snapper. If Snapper get's him, highly likely he will see it as openSUSE's fault, neither Snapper's nor BTRFS's.
That's probably true, and completely appropriate as well. For a USB stick installation, the suboptimal default configuration of snapper arguably becomes a misconfiguration. So hopefully someone's filed a bug/feature design change request under Factory.
It won't be me filing one either.
I would but I'm still unable to login; all web browsers on all OS's with Internet connection from 5 different geographic locations complain of too many redirects. And novell sites are the only sites I've ever had this experience with. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-12 01:12, Chris Murphy wrote:
I would but I'm still unable to login; all web browsers on all OS's with Internet connection from 5 different geographic locations complain of too many redirects. And novell sites are the only sites I've ever had this experience with.
Delete all novell, atachmate, suse, opensuse cookies, and make sure you allow scripts. Then try again. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWhuY4ACgkQja8UbcUWM1xytwD+OzqFbRW6HB6+P2s2T2I8K6WE AMRfZoV7bpQxW47xHogA/3zyhHPrpgd+Sg8A8oK3u+BqxssdN2KBoPOTtSa0Lax8 =hnUd -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Jul 11, 2015 at 6:49 PM, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-07-12 01:12, Chris Murphy wrote:
I would but I'm still unable to login; all web browsers on all OS's with Internet connection from 5 different geographic locations complain of too many redirects. And novell sites are the only sites I've ever had this experience with.
Delete all novell, atachmate, suse, opensuse cookies, and make sure you allow scripts. Then try again.
Yeah I did all that. I also have done clean installs of Fedora and openSUSE, baremetal and into VMs, multiple times, and tried again. And upon first and only use of FireFox, I get the same redirect errors. It's happened in Windows, and OS X, with all web browsers, even after browser resets, new users being created, through VPNs and not; and in three major North American cities with completely different Internet providers, with provider DNS and with openDNS. It's been this way for months. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-12 03:17, Chris Murphy wrote:
On Sat, Jul 11, 2015 at 6:49 PM, Carlos E. R. <> wrote:
...
It's been this way for months.
You must have something unique that the rest of the people don't have or do... What, I can't imagine. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWhyywACgkQja8UbcUWM1wr0gD/SnvJ3qkuqWoTNjsDf6eKmdTX R+I8q8ogoQ829iuWidAA/irySt16aCOYkb4hr8ggrStMutcyBtnDggrket53WVQS =myvp -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Jul 11, 2015 at 8:04 PM, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-07-12 03:17, Chris Murphy wrote:
On Sat, Jul 11, 2015 at 6:49 PM, Carlos E. R. <> wrote:
...
It's been this way for months.
You must have something unique that the rest of the people don't have or do... What, I can't imagine.
The account itself is somehow broken, but manifests in this weird way. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-12 16:43, Chris Murphy wrote:
On Sat, Jul 11, 2015 at 8:04 PM, Carlos E. R. <> wrote:
It's been this way for months.
You must have something unique that the rest of the people don't have or do... What, I can't imagine.
The account itself is somehow broken, but manifests in this weird way.
Oh, I see. Then you should contact an admin there. How, I'm unsure. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWimCEACgkQja8UbcUWM1yrAwEAlFoVGhUI9/uvHXqWxhjaEKuS q0LAtwpRF0UBV1F5Q/sBAJNmJZ2ya5djzdt53TjmLEIa6A5oH7rgMWP/vO6lDlcq =wvGT -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, Jul 12, 2015 at 10:38 AM, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-07-12 16:43, Chris Murphy wrote:
On Sat, Jul 11, 2015 at 8:04 PM, Carlos E. R. <> wrote:
It's been this way for months.
You must have something unique that the rest of the people don't have or do... What, I can't imagine.
The account itself is somehow broken, but manifests in this weird way.
Oh, I see. Then you should contact an admin there. How, I'm unsure.
I'm speculating. I don't know that it's broken. I'm suggesting something that could be unique in my case that's not true for others: my account is unique. So there might be a problem with it in a way I can't determine or fix. Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11 July 2015 at 19:06, Felix Miata
Does the OP want to risk his trial period tripping over the default BTRFS snapshot configuration in his limited space, or actually using openSUSE to do the things he wants to do?
I am not familiar with BTRFS. Last time I used Slackware it was still in beta and NetBSD didn't have it at all. I am willing to experiment. Can you point out to online resources? As it is copy on write, it might well suit a usb flash installation. -- Ottavio -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 11/07/15 16:19, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-07-11 15:53, Ottavio Caruso wrote:
Which is the best filesystem? Ext2, Ext4 without journalling or other?
What's a recommended partitioning layout in case I want to keep my applications but reinstall the base system one day? With only 16 GiB, you should go for ext4 in a single partition, no /home partition. And without journalling is a good idea, too, but you will have to manually create it, I think.
Does the live image support persistent settings? Yes, it does. But very limited updates, none to the core.
Also remember that the usb stick won't last very long. As soon as you start rw-ing stuff, it fails. Best to get one of those small 2.5" mechanical disks and velcro it to the lid. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/11/2015 10:19 AM, Carlos E. R. wrote:
With only 16 GiB, you should go for ext4 in a single partition, no /home partition. And without journalling is a good idea, too, but you will have to manually create it, I think.
Isn't ext4, without journalling, ext2? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Jul 11, 2015 at 2:49 PM, James Knott
On 07/11/2015 10:19 AM, Carlos E. R. wrote:
With only 16 GiB, you should go for ext4 in a single partition, no /home partition. And without journalling is a good idea, too, but you will have to manually create it, I think.
Isn't ext4, without journalling, ext2?
Not by a long shot. ext4 uses extent based allocation, ext2 and ext3 use indirect block mapping; ext4 supports unlimited directories, delayed allocation, and quite a pile of other features too long to list here. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-12 01:17, Chris Murphy wrote:
On Sat, Jul 11, 2015 at 2:49 PM, James Knott <> wrote:
On 07/11/2015 10:19 AM, Carlos E. R. wrote:
With only 16 GiB, you should go for ext4 in a single partition, no /home partition. And without journalling is a good idea, too, but you will have to manually create it, I think.
Isn't ext4, without journalling, ext2?
Not by a long shot. ext4 uses extent based allocation, ext2 and ext3 use indirect block mapping; ext4 supports unlimited directories, delayed allocation, and quite a pile of other features too long to list here.
Right. ext4 without journal wears less a flash stick than ext 2 :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWhugcACgkQja8UbcUWM1w/KwEAkN4Bn11+tCs+fD+Ce7qn/JaQ JBohLGjpLrRe1ithjzoA/18WhkEEURUMH+rH7pka0p0s6hXfO8VqPk10n6iL/DHQ =ZKax -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Jul 11, 2015 at 6:51 PM, Carlos E. R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-07-12 01:17, Chris Murphy wrote:
On Sat, Jul 11, 2015 at 2:49 PM, James Knott <> wrote:
On 07/11/2015 10:19 AM, Carlos E. R. wrote:
With only 16 GiB, you should go for ext4 in a single partition, no /home partition. And without journalling is a good idea, too, but you will have to manually create it, I think.
Isn't ext4, without journalling, ext2?
Not by a long shot. ext4 uses extent based allocation, ext2 and ext3 use indirect block mapping; ext4 supports unlimited directories, delayed allocation, and quite a pile of other features too long to list here.
Right.
ext4 without journal wears less a flash stick than ext 2 :-)
I think too much is made of flash wear. Ext4 on our Android/Cyanogenmod phones has journaling enabled. But, Btrfs wears about the same as ext4 without journaling, yet always effectively has journaling enabled since the fs metadata is the journal. -- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/11/2015 08:56 PM, Chris Murphy wrote:
But, Btrfs wears about the same as ext4 without journaling, yet always effectively has journaling enabled since the fs metadata is the journal.
Following that to its logical conclusion, then, a FS based solely around journalling such as NilFS2 ... No, wait, wasn't that _designed_ for such a purpose anyway? Hmmm. I have to experiment with than some. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/11/2015 08:51 PM, Carlos E. R. wrote:
ext4 without journal wears less a flash stick than ext 2 :-)
It is not abundantly clear from the man page how to create a ext4Fs without a journal. The key part is this: <quote> -O [^]feature[,...] Create a filesystem with the given features ... To disable a feature, simply prefix the feature name with a caret ('^') character. </quote> So this tune2fs -O ^has_journal /dev/sda1 will turn off a previously enabled journal. Or mkfs.ext4 -O ^has_journal /dev/sda1 will create one without the journal. How safe it is to run without journalling is debatable. Running without a journal means that your filesystem is more susceptible to corruption and data loss if it is not cleanly unmounted, for example in the event of a power loss. How much this will affect SSD I'm not sure, I would not care to try it on rotating rust. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, Jul 12, 2015 at 8:59 AM, Anton Aylward
On 07/11/2015 08:51 PM, Carlos E. R. wrote:
ext4 without journal wears less a flash stick than ext 2 :-)
It is not abundantly clear from the man page how to create a ext4Fs without a journal.
The key part is this: <quote> -O [^]feature[,...] Create a filesystem with the given features ... To disable a feature, simply prefix the feature name with a caret ('^') character. </quote>
So this tune2fs -O ^has_journal /dev/sda1 will turn off a previously enabled journal. Or mkfs.ext4 -O ^has_journal /dev/sda1 will create one without the journal.
Yes.
How safe it is to run without journalling is debatable.
The journal mainly obviates the need to run fsck after a crash or unclean umount. It doesn't itself make the fs safer. But what happens is it ensures the fs state is properly updated with a normal mount and replay of the journal. Without a journal, if you fail to run fsck at the next boot, there's a compounding chance of fs corruption with usage. Recent versions of systemd run a systemd fsck job before the ro mount of root fs, on the volume defined by the boot parameter root=UUID= so it's no longer the case that the volume is ro mounted, fstab is read to determine from fs_passno if the fs should be fsck'd or not. So now fsck is always called on root. There is an optimization for file systems that have no such thing, in the form of fsck.xfs and fsck.btrfs which are effectively null operations. Their offline file system check and repair commands are completely different and aren't tied to fsck.
Running without a journal means that your filesystem is more susceptible to corruption and data loss if it is not cleanly unmounted, for example in the event of a power loss. How much this will affect SSD I'm not sure, I would not care to try it on rotating rust.
I see no real point in running without a journal even on flash. On SSD, the wear leveling deals with the fact the journal is constantly writing to the same LBAs over and over. On USB sticks which don't have as sophisticated wear leveling, will have more wear at specific LBAs. But this should fail semi-gracefully in that the ext4 journal is checksummed, so any corruption in the journal will be detected and presumably reported in kernel messages. --- Chris Murphy -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Sun, 12 Jul 2015 09:09:37 -0600
Chris Murphy
Or mkfs.ext4 -O ^has_journal /dev/sda1 will create one without the journal.
Yes.
How safe it is to run without journalling is debatable.
The journal mainly obviates the need to run fsck after a crash or unclean umount. It doesn't itself make the fs safer.
Actually it does. Without journal there is no guarantee that related changes will happen in order or even happen at all. And it is not always possible to even detect it (consider - updating pointers to second level blocks without writing and updating block content itself). It is true that journal is not the only technique to achieve filesystem consistency. But for ext* it does make fs safer. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-12 16:59, Anton Aylward wrote:
On 07/11/2015 08:51 PM, Carlos E. R. wrote:
How safe it is to run without journalling is debatable. Running without a journal means that your filesystem is more susceptible to corruption and data loss if it is not cleanly unmounted, for example in the event of a power loss. How much this will affect SSD I'm not sure, I would not care to try it on rotating rust.
I have at least 2 ext4 usb stick done this way, without journal. One is a rescue stick, the other is for data transfer. I'm always careful with disk removal, anyway. Never had a problem Ever since I managed to corrupt an msdos floppy... I think I was writing a pascal assignment to floppy. It was the wrong disk so I exchanged it, before aborting the write operation. The result was that the second disk got the directory of the first one, but with the data of the second! I think I managed to salvage my assignment, somehow. :-} - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWinMMACgkQja8UbcUWM1wmPAD/fwV8L1IPTEdO0sjl+4YVgs9F MsBxzm2uVmhYUhp4jxIA/jsus6d6by3bbbr0y+NbKJC3suw67vkdxpxR4a0of1+c =osoh -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On July 11, 2015 4:49:13 PM EDT, James Knott
On 07/11/2015 10:19 AM, Carlos E. R. wrote:
With only 16 GiB, you should go for ext4 in a single partition, no /home partition. And without journalling is a good idea, too, but you will have to manually create it, I think.
Isn't ext4, without journalling, ext2?
No, ext3 without journaling is ext2. Ext4 has an amalgam of filesystem features that ext2 doesn't have, leaving off journaling still keeps several other features not in ext2/ext3. https://en.m.wikipedia.org/wiki/Ext4#Features Greg -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/11/2015 11:03 PM, greg.freemyer@gmail.com wrote:
Ext4 has an amalgam of filesystem features that ext2 doesn't have, leaving off journaling still keeps several other features not in ext2/ext3. Yeah, I guess up to1 exbibyte file size and 16 tebibytes of storage would be important on a flash disk. ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-12 14:04, James Knott wrote:
On 07/11/2015 11:03 PM, greg.freemyer@gmail.com wrote:
Ext4 has an amalgam of filesystem features that ext2 doesn't have, leaving off journaling still keeps several other features not in ext2/ext3. Yeah, I guess up to1 exbibyte file size and 16 tebibytes of storage would be important on a flash disk. ;-)
No, not that. The idea is, for instance, that if you are going to write a file of 1 megabyte, you assign the space in a single operation, instead of the operating system adding 1 block to the file, one by one, as it is being written. This method reduces the numbers of writes to the inodes a lot. That's the reasoning behind recommending ext4 without journal on usb sticks. I'd be interested on how to create btrfs sticks, too. What would be the best options to use? btrfs is the only w/r filesystem I know that supports compression - besides ntfs. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWiWioACgkQja8UbcUWM1waIQD8DfIrM3pwSZ0PmQ8PsWThidd2 qNo0BBNDgyvgbn317XQA/2FWiQu17jreWOrx1lM+X6UR1kw0S1QgAZoIt7No6SYc =gYGL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/12/2015 08:14 AM, Carlos E. R. wrote:
No, not that.
The idea is, for instance, that if you are going to write a file of 1 megabyte, you assign the space in a single operation, instead of the operating system adding 1 block to the file, one by one, as it is being written. This method reduces the numbers of writes to the inodes a lot.
That's nice to know. Now all we need is a operating system that can peer into the future and see how large a file is going to have to be so that it can allocate the space for it. I can imagine that being useful whether you use MailDir or mbox. </irony> -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/12/2015 09:29 AM, Anton Aylward wrote:
On 07/12/2015 08:14 AM, Carlos E. R. wrote:
No, not that.
The idea is, for instance, that if you are going to write a file of 1 megabyte, you assign the space in a single operation, instead of the operating system adding 1 block to the file, one by one, as it is being written. This method reduces the numbers of writes to the inodes a lot.
That's nice to know. Now all we need is a operating system that can peer into the future and see how large a file is going to have to be so that it can allocate the space for it. I can imagine that being useful whether you use MailDir or mbox. </irony>
Seriously though ... The old Software Tools model of a 'cp' program that is based around while (ch = readch(INPUT) { writech(OUTPUT); } isn't going to cut it any more. Even such programs are going to have to be file-system aware if the OS doesn't hide such details from them. Yes I'm perfectly aware that if STDIN gets fstat()'d as a file it can be sized and if STDOUT is a file there will be a ioctl() or something to tell if it can be preallocated. The thing that horrifies me is adding that complexity to all the programs that do anything resembling that. I know that some programs will have to accept 'streaming' input whose size cannot be predetermined. I suspect some applications will preallocated by block regardless of what's coming down the line, such as journalling and logging, knowing full well that eventually the space will be filled. But pushing this down to the individual application level places and undue burden of complexity on the application developer. While I admit to having written device drivers and schedulers and networking code for the kernels of a previous age, I've never looked at file system code. I do admit that the idea of predicting how large a file is going to be with no prior knowledge seems hocus-pocus. The alternative to a 'cp' program that migrates such an application into the kernel seems to violate many long established UNIX principles. it seems to me that if we are to avoid adding complexity to a host of presently exiting and possible future applications, and avoiding precognitive code in the kernel, that having this for the benefit of the few application that can do "walking preallocation", so to speak, like journalling and logging, that *know* they will be using all that space, seems to be adding to the complexity of the file system for the benefit of very few. The power of UNIX and Linux has always been in that, like other physical sciences such as chemistry, it takes a few basic 'elements' and few combinatorial rules and produces a wide range of useful stuff from that. This makes it a contrast to the 'sui generis' approach of OSs that preceded it and many like VMS[1] and Windows, that followed it. The whole point of the UNIX/linux OS is to make things independent of IO. That's why devices are part of the file system hierarchy. There is no "openDevice" as there is in other OSs. For example cp /dev/tty1 ... cp /home/$USER)/.face_icon ... cp /dev/random ... all have the basic "fopen()". There is no "fopen_tty()", "fopen_file()" needed. This is Linux, not something out of IBM or Microsoft. cf Software Tools, and other such white covered books by people such as Richie, Plauger, Pike, Kernigahn, Stevens, Rochkind and Aho. [1] Take, for example, the example of all the different file formats that VMS had. Just look, for example, at the text files. At one project I wrote a script that generated tables that were to be used by the C compiler. The C compiler baulked on them. So I used to editor to find out what was wrong. The editor baulked on them. Eventually I found that that the the type of text file that the editor would accept was different from the type the script generated. Found a program that fixed that. The files looked OK, The C compiler baulked on them still. Eventually I found the output of the editor was a format that was unacceptable to the C compiler. Yes, all this could have been avoided, but its should never have happened in the first place. It would be inconceivable with UNIX/Linux. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On July 12, 2015 10:11:35 AM EDT, Anton Aylward
I do admit that the idea of predicting how large a file is going to be with no prior knowledge seems hocus-pocus.
In the real world the answer is to guess large, then trim off the excess later. Later might be when the file is closed as an example. Thus if a ext4 segment is 16MB, then allocate a full 16MB when you cross a boundary. Trim it to size later. Greg -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-12 17:55, greg.freemyer@gmail.com wrote:
On July 12, 2015 10:11:35 AM EDT, Anton Aylward <>
I do admit that the idea of predicting how large a file is going to be with no prior knowledge seems hocus-pocus.
In the real world the answer is to guess large, then trim off the excess later.
Later might be when the file is closed as an example.
Thus if a ext4 segment is 16MB, then allocate a full 16MB when you cross a boundary. Trim it to size later.
This is done by the application, or by the kernel? Allocate the big segment, I mean. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWinZYACgkQja8UbcUWM1wPaQEAk6l7GiYQhAfGkz9pJNUR0EdF OWlh9GMNZijfA5qABDkA/A83ScrapoCF0Ku05nbNxkMBJ+qvyF+GS0omejtgoklt =9fO4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On July 12, 2015 1:02:14 PM EDT, "Carlos E. R."
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2015-07-12 17:55, greg.freemyer@gmail.com wrote:
On July 12, 2015 10:11:35 AM EDT, Anton Aylward <>
I do admit that the idea of predicting how large a file is going to be with no prior knowledge seems hocus-pocus.
In the real world the answer is to guess large, then trim off the excess later.
Later might be when the file is closed as an example.
Thus if a ext4 segment is 16MB, then allocate a full 16MB when you cross a boundary. Trim it to size later.
This is done by the application, or by the kernel? Allocate the big segment, I mean.
I think it is done at filesystem driver level, so the ext3 driver doesn't do this, the ext4 driver in ext3 compatibility mode does. I don't think opensuse uses the ext2 or ext3 driver by default anymore. The ext4 driver is used for ext2/ext3/ext4 file systems now. Greg -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-12 22:07, greg.freemyer@gmail.com wrote:
On July 12, 2015 1:02:14 PM EDT, "Carlos E. R." <> wrote:
This is done by the application, or by the kernel? Allocate the big segment, I mean.
I think it is done at filesystem driver level, so the ext3 driver doesn't do this, the ext4 driver in ext3 compatibility mode does.
Makes sense. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWi1XUACgkQja8UbcUWM1yvtwD/Uy8VNSlkZYiO4H2kf1QkZrqp /vBN1SAeM1RGhSPl1zEA/iRsIMtqbvYw59QpA/cN+Sl0I9BdwhgKBMsYIGrXlKPr =lTcR -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-12 16:11, Anton Aylward wrote:
Seriously though ...
The old Software Tools model of a 'cp' program that is based around
while (ch = readch(INPUT) { writech(OUTPUT); }
isn't going to cut it any more.
:-) Well, if you do that in turbopascal the file was always defined with a buffer (ie, inside the application) of, I think, 128 bytes. There was a method to allocate a much bigger size, and this resulted in a dramatic speed advantage when reading or writing files. So even then, you could avoid writing a single char to disk :-)
fixed that. The files looked OK, The C compiler baulked on them still. Eventually I found the output of the editor was a format that was unacceptable to the C compiler. Yes, all this could have been avoided, but its should never have happened in the first place. It would be inconceivable with UNIX/Linux.
Because we learned and progressed :-) - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWin18ACgkQja8UbcUWM1whSQD+M6wuwmRafEBkXx/Oqu8f8HWJ gSvzljHayLMHi9tX26EA/1EgpcJMWIZObAeD14uTpNJJPHGenI6GkdamQFMwRQfW =KVO9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/12/2015 01:09 PM, Carlos E. R. wrote:
On 2015-07-12 16:11, Anton Aylward wrote:
Seriously though ...
The old Software Tools model of a 'cp' program that is based around
while (ch = readch(INPUT) { writech(OUTPUT); }
isn't going to cut it any more.
:-)
Well, if you do that in turbopascal the file was always defined with a buffer (ie, inside the application) of, I think, 128 bytes. There was a method to allocate a much bigger size, and this resulted in a dramatic speed advantage when reading or writing files.
So even then, you could avoid writing a single char to disk :-)
Using the 'stdio.h' package, the books made it quite clear that IO was buffered. RT ... the books ? However the only 'write single character to disk' I've ever encountered was with a DEVC VAC editor. It was like the keyclicks were being echoed with disk 'ker-thumps'.
Yes, all this could have been avoided, but its should never have happened in the first place. It would be inconceivable with UNIX/Linux.
Because we learned and progressed :-)
Well, some of us did. Others wrote VAX VMS and tried competing with Bill Joy who was writing VAX UNIX. Later similar mistakes were made with MSDOS and some of the networking code, truing to "optimise" by agglomerating many operations into one complex command, trading orthogonality, clarity and verifiability/testability for a misplaced idea of 'efficiency'. I recall in particular attending the realise of the IBM Token Ring card and seeing two groups of software developers, nether of which was previously aware of the other's existence. One had been working on extending the Ethernet NETBIOS code to handle the TR adaptor. The was, IIR, APPC, or some such acronym from the mainframe world. The alter code was about 4 to 5 times the size of the NETBIOS implementation (for TR and Ethernet combined) and was another example of non-orthogonal primitives. Many of the developers from a PC/MSDOS world too one look at this and had a "DUH?" reaction which was obviously picked up by their accompanying salesmen and a little while later by the IBM types, who hustled the APPC people off stage before they killed all interest. One of the strengths on UNIX/Linux has always been that orthogonality, the 'file system' approach to IO that makes things 'look the same' to all programs and allows for 'pipes and filters' and 'sockets'. See man stdio man stdio.g man stdio_ext -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2015-07-12 20:39, Anton Aylward wrote:
On 07/12/2015 01:09 PM, Carlos E. R. wrote:
Well, if you do that in turbopascal the file was always defined with a buffer (ie, inside the application) of, I think, 128 bytes. There was a method to allocate a much bigger size, and this resulted in a dramatic speed advantage when reading or writing files.
So even then, you could avoid writing a single char to disk :-)
Using the 'stdio.h' package, the books made it quite clear that IO was buffered. RT ... the books ?
However the only 'write single character to disk' I've ever encountered was with a DEVC VAC editor. It was like the keyclicks were being echoed with disk 'ker-thumps'.
In turbopascal, you could replace or create the handler for a file. It was typical to do it for the printer or the serial port, and in these you wrote to the device one char at a time. Or not, if there was a buffer. But using the same write function calls as for a /real/ file. Same for files on disk, it was the same code. If the buffer was zero bytes or one byte (I don't remember) it would write that one char to disk immediately. I'm less familiar with C internals of the time. Or I remember less. However, on any of them, you could use msdos/bios calls that would immediately write to disk a block of /any/ size (any been smaller than 64 K, of course). Call it for a single byte, and it would be written. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlWi1+YACgkQja8UbcUWM1wulQD+IaQ1klry4/0HRXI/FydwMmvw /+S82xe5ry3MkY85wqUBAIssfGY26wkIkKmb3s6uUPtJJKkFGREiR84SkylVPR4S =ld7O -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/12/2015 08:04 AM, James Knott wrote:
On 07/11/2015 11:03 PM, greg.freemyer@gmail.com wrote:
Ext4 has an amalgam of filesystem features that ext2 doesn't have, leaving off journaling still keeps several other features not in ext2/ext3.
Yeah, I guess up to1 exbibyte file size and 16 tebibytes of storage would be important on a flash disk. ;-)
Indeed. Its going to be amazing what we will be able to do once the other semiconductor firms also manage 7nm technology. Us Greybeards may even live to see it! </irony> -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On July 12, 2015 8:04:41 AM EDT, James Knott
On 07/11/2015 11:03 PM, greg.freemyer@gmail.com wrote:
Ext4 has an amalgam of filesystem features that ext2 doesn't have, leaving off journaling still keeps several other features not in ext2/ext3. Yeah, I guess up to1 exbibyte file size and 16 tebibytes of storage would be important on a flash disk. ;-)
The bigger is is probably the block allocator. Ext3 uses a decades old scheme. Ext4 is totally different and I believe much better for flash in that it long contiguous areas of data are more likely in ext4. Greg -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (10)
-
Andrei Borzenkov -
Anton Aylward -
buhorojo -
Carlos E. R. -
Carlos E. R. -
Chris Murphy -
Felix Miata -
greg.freemyer＠gmail.com -
James Knott -
Ottavio Caruso