File systems for solid state drives (SSDs)

I have had few glitches with my SSD.
I cannot install multiple Linux Distributions due to its booting capability with GRUB.
I solved the problem by having both SSD and HDD in the system.
I have Debian installed and it goes into frozen state for unknown reason (wrong touch of a key in of the wireless typewriter). 
I solved it by going back to USB keyboard or restarting the computer.
I have a swap space in the SSD.
I do not use my computer 24/7 schedule now but download lot of torrent movies.
I watch them once and transfer the file to a spare NTS partition.
I have a SSD (240 GiB) and have not tried it to boot MultiSystem.
I think I will use it, for data storage, instead of running a Linux distribution on the fly. 
I think trying new stuff (SSD) for game is not my way of having a stable and reliable system running on HDD.
I have another way out.
I run Linux either on a USB stick (Tails, Elive) or Peppermint Live.
Debian is my favourite.
Knoppix and Puppy are my play mates.

Reproduction
File systems for solid state drives (SSDs)
Seeking-a-solid-file-system asks: I'm considering replacing my laptop's HDD for a SSD. However, I'd like to know the current state of development of Btrfs, XFS, ext4 and even ZFS for Linux. In short, is it still better (for a home/office user) to keep using ext4 or are other file systems are already mature enough to give them a try? I'd like to keep my data safe, but I'd also like to get the better performance and longevity for a SSD disk.

In addition, I've read somewhere that while using a SSD I should not have a swap partition. Is this true?

DistroWatch answers: 
Each of the file systems listed (Btrfs, ext4, XFS and ZFS) are mature and should be stable on any modern Linux distribution, at least running in a laptop. Btrfs has (reportedly) some lingering issues in RAID environments, but that is not going to affect most people. That being said, I typically recommend people stick with their distribution's default file system unless you know you have a specific case where another file system should be used.

For example, if you feel you really want to use file system snapshots, then go ahead and set up a Btrfs volume. Or if you need to transfer file system snapshots between multiple operating systems then ZFS makes a lot of sense. But if you do not have a particular use case in mind, then I suggest sticking with whatever file system your distribution recommends. (Usually this is ext4 on most Linux distributions, Btrfs on openSUSE and XFS on the Red Hat family of distributions.) None of these file systems is particular suited for (or a poor match with) SSDs.

Moving on to the swap space question, I think it is worth looking at where the advice against using swap on SSDs came from. When SSDs first hit the market one of the big drawbacks was that storage areas of an SSD could wear out after being written to a certain number of times. This meant that the operating system would need to work around burned out areas of the storage device. For most files this was not a big problem, but if a file system kept using the same specific area of the SSD over and over, that section of the SSD could be worn out. This was considered a problem for file systems that used a journal, for example, because the journal is written to the same place on disk each time.

This gave rise to the idea that SSDs should not be used with journaled file systems, swap space or other region-specific tasks. However, over the years SSDs became more resilient and could be written to for years before burning out. Burning out an SSD has not been a serious concern for at least a decade. Even with enterprise-level workloads, SSDs will last for years. In short, don't worry about how you use the SSD, its endurance should be about the same as a spinning hard drive's.

Specifically on the topic of swap space, the advice you read was backward, in my opinion. Since reading from random locations on an SSD is faster than from a spinning drive, SSDs are ideally geared toward being used for a swap partition.